Documentation

php2go documentation

A practical user guide: prepare a ZIP, choose an entrypoint, run allowed commands, download the artifact, and understand common compiler errors.

Fast path to the first build
  1. Pack the project into a ZIP without secrets or junk files.
  2. Make sure the entrypoint exists, usually public/index.php.
  3. Run report/check/deps before compile.
  4. Download the artifact and run the binary using README_RUN.
COMPAT

PHP compatibility

php2go aims to preserve PHP behavior where it matters while generating fast Go code. The more static and understandable the project is, the fewer fallbacks appear in the result.

Usually compiles well

  • Classic MVC apps, routers, controllers, services, and templates.
  • Composer autoload, ordinary classes, inheritance, interfaces, and many standard PHP functions.
  • Arrays, strings, JSON, dates, files, sessions, and HTTP request handling.
  • Typed code and old untyped code when class relationships can be inferred.

Needs attention

  • Fully dynamic calls such as call_user_func($_REQUEST[...]) and new $unknown.
  • Rare PHP extensions, custom stream wrappers, complex GD/Imagick/OpenSSL edge cases.
  • Projects where important logic lives in random test/dev files or is conditionally included.
  • Code tied to process-global state, unusual ini settings, or shell commands.
Why report matters

The report command shows what the compiler saw: classes, functions, reachable code, fallbacks, and risky spots. It is the first document support needs.

Direct generation example

When types and array shape are clear, the compiler can replace PHP dynamics with ordinary typed Go code.

PHP source
final class UserService
{
    public function name(array $row): string
    {
        return trim((string) ($row['name'] ?? ''));
    }
}
Typical Go output
func (this *UserService) Name(v_row php.Array) string {
    return php.Trim(php.ArrayGetStringDefault(v_row, php.StrKey("name"), ""))
}