Перейти к сводке вопросов и ответов 2

Go

В продолжение предыдущей статьиПерейти к сводке вопросов и ответов, прошло больше месяца. Сегодня я подытожу свои ответы о Go за более чем месяц.

После приблизительного подсчета более чем за месяц я ответил примерно на 18 вопросов, связанных с Go, в основном с двух платформ, segmentfault и zhihu. Я надеюсь добавить больше платформ позже, таких как stackoverflow, интересные темы github.

Недавно я пишу небольшой инструмент, чтобы помочь себе отвечать на вопросы на разных платформах, а также упростить сводку вопросов каждого месяца. Пишу немного медленно, надеюсь к концу месяца закончу.

Начинается часть тела.

Как разобрать данные карты [строка] строки, извлеченные Redis, в целевую структуру в golang?

В основном связаны с отражением.

Проблема в основном заключается в том, как разобрать строку формата символа даты в элемент типа time.Time, если на карте есть строка даты, а для структуры возврат Reflect.Kind() может указывать только на то, что тип поля является структурой и не может определить реальный тип, что может быть реализовано с использованием синтаксиса запроса типа переключателя Go.

Чтобы добавить, что это не было упомянуто в ответе.

При реализации общего метода map to struct нам проще думать о поддержке базовых типов, но для структурных типов слишком много возможностей, как более гибко решить задачу? Я думаю, это можно реализовать с помощью хуков, то есть, если пользовательский тип должен поддерживать преобразование карты в структуру, это можно реализовать, добавив методы хука в пользовательский тип, такие как UnmarshalMap. Как реализовать можно обратиться к encoding/json.

Разумеется, эта работа уже была проделана, обратитесь к пакету на github,mitchellh/mapstructure. Упомянутый выше крючок также поддерживается.

Как golang элегантно реализует коды ошибок?

В Go есть своя философия обработки ошибок. На этот вопрос я просто коротко ответил, простая идея, я определил ошибки на уровне пользователя и ошибки на уровне системы. Часть 1Сводка вопросов и ответовАналогичная проблема.

Голанг, когда вернуть ошибку, когда паникул?

Мое предложение: если ошибка серьезно повлияла на логику службы, если ошибка находится в пределах прогноза, мы должны вернуть ошибку, записать журнал и не нуждаться в ручном вмешательстве для восстановления, в противном случае рекомендуется паниковать.

Например, в обычных условиях при запуске службы необходимо выполнить полную работу по инициализации, чтобы убедиться, что каждый компонент работает нормально. Если инициализация не удалась, то дальше спускаться не надо, надо паниковать и подсказывать.

Как реализовано время Голанга?

Название вопроса выглядит довольно большим, но основное беспокойство вызывает отношение преобразования между несколькими основными константами. Есть в основном три времени, а именно время unix, время стены и абсолютное время. Здесь есть относительно важная формула преобразования, которая немного сложнее, когда нужно учитывать пингрунниан.

Не так много вступления, давайте посмотрим ответ сами.

Когда использовать указатели, а когда обычные объекты в golang?

На самом деле есть два момента: во-первых, если структура данных относительно велика, рекомендуется использовать указатели, и копирование значений не произойдет. Во-вторых, если вам нужно изменить структуру, вы должны использовать указатель. Конечно, если это ссылочный тип, такой как chan, slice, map, вам не нужно рассматривать эту проблему.

Почему make(T, args) в Golang возвращает T вместо *T?

сделать цели ссылочными типами Go, а именно chan, slice и map, а новые цели — указателями. Почему не создаются указатели возврата для ссылочных типов? Конечно, это немного похоже на предыдущий вопрос, потому что ссылки не имеют таких проблем с типами значений.

Добавьте карту к фрагменту карты в цикле, данные в фрагменте карты — это все данные последнего добавления.

Подобно пункту знаний в предыдущем вопросе, карта является ссылочным типом.Даже если срез присваивает несколько переменных карты через добавление, его внутренний указатель является одним и тем же адресом.

Какие ссылочные типы Golang не должны быть добавлены при объявлении, которые недоступны в функциональном параметрическом и возвращаемом типе значений

Как и в предыдущем вопросе, подробности см. в ответе.

В моем понимании, четыре вопроса, отсчитываемые отсюда, в основном аналогичны очкам знаний, Проще говоря, это проблема суммы «сделано» и «ново». По сути, это вопрос того, что находится внутри переменной.

Почему в языке go так мало внутренних функций среза?

Честно говоря, я не понимаю, почему команда Go не предоставила соответствующую стандартную библиотеку для слайсов, например строкового типа, чтобы сделать слайсы более удобными. Но на самом деле, даже если такого пакета нет, обычные добавления, удаления, модификации и проверки слайсов можно реализовать, но это немного халтурно. Как это сделать, смотрите мои вопросы и ответы.

Эквивалентное сравнение golang напрямую сравнивает адреса?

Первое, что нужно сказать, это то, что сравнение на равенство в Go сравнивает значения, а не адреса. Сопоставимые типы переменных в Go встроены, и сравнивать можно практически все типы, включая интерфейсы и структуры. Две сравнимые переменные заранее должны быть одного типа. Но следует отметить, что интерфейс является неопределенным типом, поэтому он сравнивает не только значения, но и конкретные типы.

После ответа на этот вопрос я вдруг вспомнил, что я также использовал метод Reflect.DeepEqual в пакете отражения некоторое время назад при сравнении двух структур одного типа, что действительно является пустой тратой ресурсов.

Как запретить прямое построение экспортируемого типа в golang, он должен быть построен через новую функцию?

Для других языков oo очень просто реализовать основные требования, если вы определяете соответствующие свойства private-члена и управляете входными параметрами через конструктор.

Так как же Go это делает? На самом деле тоже очень просто, идея похожа на oo. Просто мы заменили конструктор в языке oo фабричным методом в Go, а приватные переменные стали приватными свойствами-членами уровня пакета Go. Нам просто нужно создать экземпляр, определив указанный экспортируемый фабричный метод.

Начало работы, продвинутый язык GO, какие-нибудь рекомендации хороших книг?

Я рекомендую несколько книг от начинающих, от среднего до продвинутого. Заинтересованные друзья, пожалуйста, проверьте ответ для деталей.

Как бы вы оценили новый пакет плагинов, добавленный в стандартную библиотеку Go?

Ответ на этот вопрос заключается в том, что я покупаю в первую очередь. Прочитав несколько статей о примерах использования плагинов в среде, в общей сложности ушло около трех-четырех часов. Пакет плагинов дает Go возможность реализовать динамическую загрузку модулей, добавляя новые функции без перекомпиляции основной программы. Это имеет некоторую ценность.

Однако пакет плагинов также имеет некоторые проблемы, и при его использовании будут использоваться некоторые ограничивающие факторы. Но если мы ясно это понимаем, мы все равно можем понять, в каких сценариях мы должны его использовать. Смотрите ответ для конкретных ограничений.

Как go build скрывает глобальные статические строковые переменные?

Я не нашел хорошего способа решить эту проблему.Все, что я могу придумать, это решить ее с помощью шифрования и дешифрования. Конечно, в реальном проекте мы можем реализовать это, внедрив внешние сервисы, такие как функция шифрования конфигурации k8s, и используя ectd для управления конфигурацией.

На языке го, в чем разница между пустым бесконечным циклом и тяном, который блокируется навсегда?

Горутины упреждающие, что отличается от традиционной модели сопрограмм. Однако это не является полностью упреждающим.В случае с одним ядром ЦП все равно должен активно входить и выходить из ресурсов, а пустой бесконечный цикл всегда будет занимать ЦП, что является серьезной тратой ресурсов, и блокировка чан будет продавать ресурсы ЦП для достижения параллелизма. Это должно быть самое большое различие между ними.

В дополнение к общей блокировке реализации chan, Q&A также представляет некоторые другие способы достижения аналогичных эффектов. Заинтересованные друзья могут просмотреть ответ.

В чем разница между fmt.Println и прямой печатью в Golang?

println в основном используется самим Go, например исходный код, стандартная библиотека и т. д., а fmt используется разработчиками Go. И следует отметить, что println не гарантирует совместимость и может не существовать однажды в будущем, но функции в fmt не имеют таких проблем.

Конечно, их использование и эффекты также различны, например, вывод println соответствует стандартной ошибке, а не стандартному выводу.

Как читать исходный код Голанга?

Этот ответ был большим проектом и занял у меня около трех недель по частям. Какова причина?

Я выдвинул идею чтения исходного кода, который разбит примерно на три шага, соответственно примерно понимание использования, знакомство с архитектурой и принципами анализа. Недавно я думал о том, не начать ли самому анализировать исходный код, поэтому я решил начать с первого шага и написал весь исходный код Go, чтобы получить общее представление о задействованном контенте и его использовании. Всего задействовано более 40 деталей, так что это занимает много времени.

Первый шаг - понять использование этого произведения, некоторые части достигают понимания использования, но некоторые части просто достигают уровня понимания. Если вы хотите прочитать исходный код полностью, это сложно, но возможно прочитать. Приготовьтесь ждать подходящего момента, чтобы начать план чтения исходного кода системы.

При работе с базой данных golang вам нужен go func()? Чем он отличается от выхода асинхронной операции Python?

Часть 1Перейти к сводке вопросов и ответовЕсть похожие проблемы. Насколько я понимаю, предпосылка использования go func заключается в том, что должны быть задачи, которые можно выполнять параллельно, что является важной предпосылкой.

Много раз все изучают Go с целью параллелизма в Go, но изучив его, они обнаруживают, что вообще не могут его использовать, что очень угнетает.Я всегда чувствую, что с этим что-то не так. В общем развитии бизнеса, особенно развитии веб-бизнеса, существует не так много сценариев, использующих параллелизм. Что касается проблемы производительности параллелизма, то сервисный фреймворк уже помог нам ее осознать, вмешиваться вообще нет возможности, чтобы по-настоящему научиться параллелизму, мы не можем каждый день просто добавлять, удалять, изменять и проверять.

Резюме готово! Если ответ неверный, поправьте меня. Наконец, спасибо за чтение, резюме кажется довольно скучным!


波罗学的微信公众号