PHP 高频追问
1. 你为什么核心业务更喜欢用 PHP，而不是全部换成 Go？
推荐回答
我不会从语言好坏去看，而是从业务特点看。像复杂业务规则、后台配置、状态流转、和产品运营频繁协作这类场景，PHP 的开发效率和团队协作成本更有优势。 Go 我也会用，但我更倾向把它放在实时链路、高并发服务、消费者和批处理这类更适合服务化的场景。
你可以挂回项目
- 海外业务平台：订阅、支付、退款、后台规则更适合 PHP
- 推广 ROI 线：后台和配置用 PHP，实时链路和消费者用 Go
2. PHP 做复杂业务时，你最看重什么？
推荐回答
我最看重三件事：
- 业务状态模型是不是清楚
- 边界和异常流是不是提前想清楚
- 后续扩展和治理是不是可控
很多人把 PHP 理解成“写接口快”，但我更关心它能不能把复杂规则真正稳定落地。
3. PHP-FPM 打满了你怎么排查？
推荐回答
我会先分层看：
- 是业务慢还是依赖慢
- 是慢 SQL 还是外部接口超时
- 是偶发峰值还是持续打满
- 有没有缓存命中不足或某些热点请求
如果是 PHP-FPM 本身打满，我会结合慢日志、请求分布、数据库和外部依赖去看，而不是只调大 worker 数。 调参数只能缓解，真正要解决还是得回到慢链路本身。
4. PHP 项目怎么做依赖注入和解耦？
推荐回答
我的理解是依赖注入不是为了框架感，而是为了把业务逻辑和具体实现解耦。 比如支付、消息通知、三方渠道适配、模型能力接入，这些都适合通过接口和容器做抽象，这样后面扩展新渠道或替换实现成本更低。
项目里怎么讲
你可以讲不同支付渠道、不同广告渠道、不同 AI 能力接入都适合走这套抽象。
5. PHP 怎么做高并发？
推荐回答
PHP 本身不是高并发问题的全部答案。真正做高并发时，我更关注：
- 缓存
- 异步解耦
- 限流
- 幂等
- 热点隔离
- 把不适合 PHP 同步处理的部分拆到 Go / MQ / 后台任务
也就是说，PHP 在复杂业务主链路里完全可以很好用，但不能把所有高峰压力都堆在同步请求里。
6. Swoole 和传统 PHP-FPM 你怎么选？
推荐回答
如果是典型后台和复杂业务系统，我更习惯传统 PHP-FPM，因为模型清晰、治理成熟。 如果场景是长连接、WebSocket、协程并发、实时流式处理，Swoole 更有价值。 我会根据场景选，不会为了“更快”就盲目上 Swoole。
7. 你怎么避免 PHP 项目越做越乱？
推荐回答
我会重点抓这几个点：
- 模块边界清楚
- 状态定义清楚
- 统一返回和错误码
- 关键逻辑服务化
- 日志和监控先补齐
- 公共能力抽象但不过度设计
业务复杂时，最怕的不是代码多，而是规则散、状态乱、异常全靠猜。
8. PHP 做支付 / 订阅链路最难的是什么？
推荐回答
不是把回调接上，而是状态一致性。 比如支付成功、退款、恢复订阅、回调乱序、重复通知、权益同步，这些都可能同时影响同一笔业务。 我一般会先把状态机定义清楚，再通过幂等、补偿和关键日志把异常流兜住。
9. PHP 里你怎么做代码可维护性？
推荐回答
我比较重视的是：
- 业务规则不要散在 controller 里
- 复杂链路下沉到 service / domain 层
- DTO / VO / 枚举 / 状态机清晰
- 接口契约和测试点先明确
- 公共逻辑抽象要有边界，避免过度封装
10. 技术总监如果问“你是高级 PHP 工程师的依据是什么”，你怎么答？
推荐回答
我觉得不是因为我会多少语法点，而是我长期用 PHP 承接复杂业务系统，包括订阅、支付、退款、交易、后台和多服务协同。 我做的不是单点接口，而是业务建模、方案拆解、状态治理、联调上线和问题治理，这些更接近高级 PHP 工程师真正的职责。