工作里两个都用，经常被问"到底该用哪个"。我的答案永远是看场景，但"看场景"太虚了，这篇写点具体的判断依据。
我实际遇到过的选型场景
先列几个真实决策，后面说规律。
场景一：给现有 PHP 后台加一个批量导出功能
数据量几万到几十万行，导出成 Excel。原来的做法是 PHP 直接查全量、拼数组、塞进 PHPExcel，内存直接爆。
我的选择：加了 Go 服务。因为导出是典型的 CPU + 内存密集，而且可以异步化——点按钮之后丢进队列，Go 慢慢跑，跑完通知下载。
场景二：一个简单的短链跳转服务
需求就是查一下 Redis，302 跳转。QPS 预估几千。
我的选择：PHP。因为现有的 PHP 框架里已经有 Redis 封装、有监控、有部署流程，写一个 controller 二十行搞定。用 Go 的话得重新搞一套部署、监控、日志，为了"性能好"付出了不成比例的运维成本。几千 QPS 用 PHP-FPM 完全扛得住。
场景三：定时对账任务
每天凌晨比对两个系统的订单数据，有差异的发告警。
我的选择：Go。因为要并发拉两边的分页接口、要严格控制内存、要能长时间运行不超时。PHP CLI 脚本也能写，但处理并发和内存上限比较别扭。
场景四：给运营做的一个数据看板
几个图表，数据来自几个 SQL 查询。
我的选择：PHP。开发速度快，模板渲染现成，运营改需求的时候我半小时就能调一次。用 Go 写模板我得先想清楚数据结构、定义 struct、处理错误……需求一天变三次的时候这个成本受不了。
我总结的判断依据
把上面的经验抽象一下，大概是这几条：
用 Go 的情况
1. 单个请求要消耗大量资源
PDF 生成、图片处理、报表导出、视频转码这类。PHP 有 memory_limit 和 max_execution_time，处理大对象很别扭；Go 可以精确控制内存，还能流式处理。
2. 需要长驻和并发
websocket 服务、消息消费、定时任务、爬虫。PHP-FPM 的模型是"一个请求一个进程"，做长连接效率低；PHP CLI 能做但是进程管理得自己来。
3. 性能敏感且压测证明 PHP 到瓶颈了
注意后半句。只有压测数据说 PHP 不行了，才换 Go。 我见过太多"感觉 PHP 慢"就重写的项目，重写完发现瓶颈其实在数据库。
4. 需要单文件分发
给客户部署一个内网工具，Go 编译出一个二进制扔过去就能跑。不用装运行时、不用配 php-fpm。这个场景 Go 优势极大。
用 PHP 的情况
1. 需求变化快、以 CRUD 为主
后台管理系统、运营配置页、活动页面。这类代码的价值在于改得快，PHP 的热更新和宽松类型在这里是优势不是劣势。
2. 生态里已经有现成方案
支付、短信、各种第三方 SDK，PHP 的现成包通常更成熟。Go 的 SDK 有时候是社区维护的，质量参差不齐。
3. 已经在用 PHP 框架，且需求能覆盖
Laravel 的队列、定时任务、缓存、ORM 都很成熟。为了一个功能引入第二套技术栈，团队要维护两套部署、两套监控、两套日志，这个成本经常被低估。
4. 团队成员更熟 PHP
这条看起来不技术，但可能是最重要的。
混用的代价
两边都用不是免费的，我踩过的坑：
部署变复杂。 原来一套 CI/CD，现在要两条流水线，两套健康检查、两套日志采集。
本地开发环境变重。 新人要装 PHP、Composer、Go、还可能要有 Docker 跑依赖服务。
跨语言调用要设计。 Go 服务和 PHP 之间怎么通信？HTTP 还是消息队列？数据格式谁定义？错误怎么传递？
我的做法是：Go 只做无状态的纯计算/IO 服务，通过 HTTP 或队列被 PHP 调用，不反向依赖 PHP。 这样依赖方向单向，Go 服务可以独立测试和部署。
监控要统一。 两边都要打 trace id，不然一个请求跨两个服务，出问题没法串起来。我们用 OpenTelemetry，两边都能接。
日志格式要统一。 都用 JSON，字段名对齐（trace_id、user_id、level 这些），不然日志系统里搜不出来。
我对"什么时候不该引入第二套"的看法
有个经验值：如果新语言带来的收益不能覆盖运维成本，就别引。
具体点：如果一个 Go 服务省下的服务器成本是每月 200 块，但团队要为此多维护一套部署和监控，那就不划算。除非：
- 收益是量级差异（比如响应时间从 2 秒降到 50ms，用户体验质变）
- 或者 PHP 根本做不了（长连接、单文件分发）
我见过最亏的一个决策是：把一个日活三千的后台系统从 PHP 重写成 Go，理由是要"提升性能"。重写花了四个月，性能提升对用户完全无感，然后因为 Go 的模板和表单处理不如 PHP 方便，后续每个需求开发时间增加了一倍。
关于"Go 更现代"这种说法
这个论点我不太认同。
Go 的类型系统和错误处理确实更严格，但 PHP 8 之后有类型声明、有 readonly、有 enum、有 match、有命名参数、有 JIT。语言特性上的差距没有想象中大。
真正的差异在运行时模型：
- PHP：请求进来 → 初始化 → 执行 → 销毁。简单、无状态、不怕内存泄漏（进程结束就清）
- Go：常驻进程。要自己管内存、管连接池、管 goroutine 泄漏
PHP 的模型对开发者友好，Go 的模型对资源利用友好。这是取舍，不是先进落后。
我现在的默认选择
如果让我给一个刚起步的项目建议：
先全用 PHP。 因为它能覆盖 80% 的需求，开发快，招人容易，生态成熟。
遇到下面任一情况再引入 Go：
- 压测数据明确显示 PHP 是瓶颈
- 需要长连接 / 常驻进程
- 单个操作吃大量内存或 CPU
- 需要分发给客户独立二进制
不要因为"以后可能会需要"就提前上 Go。
我犯过这个错。有个项目一开始就按"未来要支持百万用户"设计，用 Go 写了一堆现在完全用不上的分层和抽象，结果业务方向变了，那些代码全废了。
最后一句
语言选择的影响，远小于数据库设计、缓存策略、接口划分这些决策。
选什么语言，只要团队能维护、能满足需求，就是对的。花两周纠结 Go 还是 PHP，不如花两周把数据库索引和慢查询理一遍。