问题探讨：比如PHP还有没有未来？composer最佳实践？单测到底怎么写？

最近在社区里总能看到类似的焦虑：PHP还有没有未来？Composer到底怎么用才算专业？单元测试写了跟没写一样怎么办？

这些问题其实串在一起，就是一名PHP开发者从“会写”到“写好”必经的三个门槛。今天不灌鸡汤，就着这几个问题聊聊我的真实想法。

PHP还有没有未来？

先说结论：PHP的“未来”不是会不会死，而是会以什么形态活着。

唱衰PHP的声音年年有。新的语言层出不穷，Go、Rust在基础设施领域攻城略地，Node.js霸占前端工具链，Python统治AI生态——看起来PHP确实不在聚光灯下。

但如果你打开真实的互联网服务器统计，PHP依然运行着全球超过七成的网站。这不是因为开发者恋旧，而是因为PHP在Web领域拥有极致的性价比。PHP 8.4发布后，JIT加上更严格的类型系统，性能上已经不输大多数解释型语言，而它的部署成本依然是最低的——上传文件就能跑，这仍然是创业公司最需要的特性。

另一个更关键的信号是Laravel。Laravel把PHP的现代性拉到了一个不可思议的高度，队列、事件、Eloquent、Horizon、Octane——每一层都在用优雅的方式解决工程复杂度。什么语言生态能在保持低门槛的同时，进化出这样完整的应用框架？

所以别问PHP还有没有未来。只要WordPress还在滋养内容互联网，只要Laravel还在为中小项目提供最高效的交付方案，PHP就不是墙角里的落灰工具，而是正在换代的常青树。

Composer最佳实践

Composer可能是PHP生态里被误解最深的工具——多数人只把它当`npm install`用，也就停在了“依赖管理器”这个层面。

就我自己的经验，真正用好Composer，至少要过三关。

第一关：版本约束的艺术。别看官方文档的约束写了一大串，我的建议就一条：生产项目用`^`锁定次版本，自己的包里用精确的`|`约束保证兼容。拉依赖时带上`--prefer-dist`，在CI里坚持用`composer.lock`部署。版本漂移的坑，一次就能让你记住lock文件的珍贵。

第二关：Composer是自举器，不只是管理器。当你发现自己的`composer.json`里塞满了`"scripts"`时，才真正开始理解Composer。把代码格式化、静态分析、单元测试这些工作流串进`composer test`里，你的队友会感激你的。我曾经把一个项目的部署流程从7步shell命令压缩成`composer deploy`，那一刻才真正体会到什么是“工程效率”。

第三关：autoload优化。`composer dump-autoload -o` 生成classmap，在生产环境能显著减少I/O开销。如果项目够大，试试`--classmap-authoritative`——前提是你确保没有动态类名依赖。这些细节，才是composer“最佳”的体现。

单测到底怎么写？

我见过太多团队写单测是为了凑覆盖率，把`assertEquals(1, 1)`这种测试写得行云流水——然后遇到重构就全线崩盘。这根本不是单测，是安慰剂。

我的原则是：单测锁行为，不锁实现。

写测试前先问自己：这个方法的输入是什么？输出是什么？对外部系统的调用是什么样的？把这三个问题回答清楚，然后围绕“行为契约”来编写用例，而不是去断言某一行代码执行了几次。

另一个实用的切入点是：从bug开始积累。你修过的每一个线上bug，都应该对应一个回归测试。先把那些“曾经坏的”场景锁住，再谈测试覆盖。这比对着代码空想测试用例更符合人性的直觉。

不要拒绝写测试的笨办法。如果你们团队刚推单测，允许一些看起来很傻的直接断言——先把习惯建立起来，后面再慢慢引入数据提供器、测试富领域对象、做行为模拟。单测不是一蹴而就的体操，它是一点点夯实的地基。

写在最后

回头看看这三个问题，其实都是同一个问题：一个PHP开发者想把自己的代码做得更体面些。

PHP的未来不在于语言本身，而在于我们这些写PHP的人，是否愿意用现代工程的标准去要求自己。用Composer治理依赖，用单测守住代码行为的底线——这是比争论“PHP还有没有未来”更有意义的事。

你把手里的活干漂亮了，语言就有未来。你尊重代码质量，单测自然有章法。工具是死的，用工具的人是活的。这条路上没有银弹，但每一步扎实都算数。