Иван Корюков

В списке процессов должно быть видно что выполняется скрипт.
Кроме того, вы можете добавить в свой скрипт разного рода вывод в консоль (или сразу в файл), а при запуске скрипта через крон перенаправить вывод в файл. Далее уже этот файл открываете с помощью tail с опцией непрерывного чтения (насколько помню tail что-то такое умеет), ну и в реалтайме наблюдать что выводит скрипт запущенный через крон.

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

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

Более реалистичный вариант - выделение какого-нибудь service locator'а, который тоже лучше передавать руками, но часто его делают доступным глобально через static или singleton (который сам строится на static).

Ваше решение в корне не верно. Класс, всё содержимое которого статическое это уже не класс, а набор функций.

1) Go компилируемый, само собой скорость выше, но если вы на маленьком сайте упираетесь в скорость исполнения кода, то проблема скорее в коде, и выбор более быстрого языка избавит вас только от симптома, но не от болезни
2) на seo влияет только то ЧТО вы отдаёте пауку. Не важно на каком языке пишется программа, которая отдаёт html
3) Программа написанная на go сама работает как сервер. Более того, это не какой-то сервер приложений, как например tomcat, нет, вы сами будете писать цикл обработки входящих соединений - т.е. вам необходимо этот самый серер реализовать. В отличие от php+apache, где в качестве сервера выступает apache, который при необходимости вызывает php. Ставить ли apache или nginx перед go сервером вы решаете сами.
4) Поддерживает. На скорость работы СУБД не влияет то, на каком языке написана программа, которая к ней обращается.
5) Фреймворков уровня Yii2 или Symfony не наблюдается. Ситуация такая же как и с NodeJS - что-то есть, но комбайнов нет.
6) Если что-то может слушать соккет - на этом можно написать сайт. Любой. Другое дело, что сайты визитки на Go не пишут (только ради забавы), а крупные сайты вообще имеют сложную архитектуру, такую что язык уже не имеет значения.
7) Для php разработчика - да. Как минимум вы меняете скриптовый язык на компилируемый. Это значит что любое изменение кода требует компиляции, остановки работающего сервера, загрузки бинарника на его место и запуск. Кроме того вы меняете Stateless модель работы кода на полноценно работающую программу. Если на php у вас скрипт запускался заново при каждом http запросе, то программа на go запускается один раз и после этого принимает множество запросов.

Как вариант: разбиваем строку по точке с запятой.
Если надо добавить слово, то кладём его в последний существующий элемент (это всегда пустая строка) и добавляем в конец массива новую пустую строку.
Если удалить слово - то ищем индекс слова в массива, удаляем.
В итоге джойним обратно по точке с запятой. Т.к. в конце есть пустая строка, то итоговая строка будет заканчиваться точкой с запятой.

передавать через контроллер, но при этом придется совершать в нем множество проверок, типа проверка на уникальность пользователя, пустоту полей, идентичность паролей

Этим вы делаете толстый контроллер. На самом деле форма - это модель. Это страница на которой есть своя логика, и в зависимости от действий пользователя она меняет своё состояние, которое и отображается пользователю.
И вот логика формы реализуется в модели формы, которая в свою очередь может дёргать более глубокие слои приложения.
Таким образом задачей контроллера становится только получение данных из http запроса, засовывание их в модель и вызов у модели одного-двух методов.

Вангую - щас понабегут люди с советами типа "юзай mongodb"...
Вообще можно использовать EAV. Это когда атрибуты сущности хранятся не горизонтально (столбцы в таблице), а вертикально (один атрибут - одна строка). Дополнительно нужны таблицы, которые будут хранить список типов сущностей, список типов атрибутов и связи типов сущностей и типов атрибутов.

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

Логично, в php запущенном из консоли нет document_root

JSON.parser принимает строку и делает из неё объект/массив, в вашем случае это объект.
Если вы используете jQuery для выполнения ajax запросов то достаточно будет указать dataType:"json" и результат сразу будет в виде объекта.

Возможно команда иначе называется. Или же на сервере совсем нет php.

Встраивание iframe делается браузером. Это браузер видит что необходимо в этой странице подгрузить ещё одну, и подгружает. Сама же страница, тобишь сервер, не знает что его показывают в iframe, поэтому $_SERVER['SERVER_ADDR'] всегда будет показывать реальный адерс сервера.

Где-то есть редирект с www на без www, вот оно по кругу и редиректит. Браузер это заметил и выкинул ошибку.