大家好，我是码农先森。
最近在闲逛 v2ex 社区时，看到有个讨论 PHP 项目能否直接迁移到 Go 语言上的话题。我大概简述一下提问v友的原话，他们因为项目性能的问题在 2020 年时，从 Laravel 框架迁移到了 Hyperf 框架，在完成迁移之后，性能确实提升了一大截。但这位v友发现 Hyperf 框架的作者，对该框架的积极性已经不高，这一点体现在他近期遇到的技术问题，在 Github 上提 Issue 几乎已经不在被回答了。由此引发了他的焦虑，他怕 Hyperf 框架后面停止更新，假设遇到致命的 Bug 无法解决，那么项目的结果将彻底黄了。
因此，他开始着想能不能把项目直接迁移到 Go 语言上，但又担忧用 Go 语言全部重写，时间成本和技术成本又太高了。其实很多v友对这个话题都很感兴趣，大家也提了很多的建议给他。因为我自己也是从 PHP 转到 Go 的，深知 PHP 的一些技术瓶颈和天生的缺陷。
不仅是这位v友遇到这个问题，我相信大多数的PHP程序员，都会遇到同样的问题。 在刚开始遇到性能问题时，会优先考虑 Swoole、Workerman 之类的框架，如果在使用了这些框架也无法满足其性能的情况下。便会开始考虑其他的语言，近年来 Go 语言风靡全球，因此很多人都会优先选择 Go 语言。
那由此就产生了一个很棘手的问题，在业务快速发展，又不能停机的情况下，如何能快速的将项目迁移到 Go 语言上呢？在这个问题上，我个人有这三方面的建议，希望能对大家有所帮助。
首先，一开始不要想着一口吃成大胖子直接全部重写，这样操作带来的复杂度和时间周期会很长。一旦时间拉的很长，大家开发的积极性，便会逐渐地降低。我遇到过很多类似的情景，刚开始时大家都满怀激情，但随着时间的推移，大家的耐心便一点点被消磨掉了，在这种状态下重写的项目会产生很多的问题，如果达不到预期的话，会很打击大家的信心。因此，我们要准确的分析现有项目中的问题，到底是业务逻辑的问题，还是数据库的问题，还是语言本身的问题。如果是语言的问题，需要拆解出具体的接口，把这个接口的业务单独用 Go 语言来实现，然后上线之后再用流量分发的方式，将一部分的流量转发到 Go 语言上，如果稳定之后便可以直接把这个接口流量全部切换到 Go 语言。采用这种单点迁移的方式，能够很快的验证 Go 语言所带来的性能价值，这样做短期内就能看到效果，能让大家最直接的感受到性能的跃身，对后期的工作开展也会很顺利。
其次，迁移项目是一个系统性工程，我们在刚开始尝到甜头时，都会比较兴奋与得意。我觉得可以得意，但是不能忘本。大家本意上还是想提高整个项目的性能，不能遇到一个就单点解决一个。做好一个长期的规划，这一点尤其重要。还有就是要认识到 Go 语言并不是万能的，别妄想任何问题都能通过 Go 语言来解决。每一门语言或技术，都有自身擅长的领域和方向。比如 Go 语言在生态和轮子方面并没有那么多，如果长期习惯了 PHP 的拿来主义，用 Go 可能很不顺手。这一点需要自己有个清晰的认知，否则会很打击自信心。
最后，大家要做一名长期主义者，不要三天打鱼两天晒网，我见过很多的人，今天觉得 Go 语言好，便用 Go 语言。明天又觉得 Java 好，然后又开始尝试。如果遇到点问题，解决不了，一旦听别人说 Rust 简单好用性能高，结果又跑到 Rust 的领域去了。其实，每门语言的本质都是相通的，不要总是认为这个好那个好，我们要能够看透本质。在电影教父里面有这样一句话，花一分看懂事物本质的人和花一辈子的人，两者的命运会截然不同。
从近些年来看经济的不景气，造成了不仅是互联网行业，其他行业也都面临着停滞的问题。在我们编程行业里，尤其表现在很多的开源项目都停止了更新，毕竟大家也不能靠爱发电。俗话说背靠大树好乘凉，我们在选择一些开源项目时，尽可能选一些有背景大公司的，像一些个人开发者要尽可能的避坑。大环境我们改变不了，我们能做的是让自己做一些正确的选择。著名作家罗曼·罗兰曾说过：世界上只有一种真正的英雄主义，就是认清了生活的真相后还依然热爱它。借此我也想把这句话送给大家，让大家对编程依然保持热爱，而不是只为了吃饱饭，做一名热爱编程的长期理想主义者。
感谢大家阅读，个人观点仅供参考，欢迎在评论区发表不同观点。
说个题外话，由于近年来大环境不好，我开始研究了些副业，也分享给大家，如果有需要的朋友可以在公众号内私信「副业」不喜略过哈。
欢迎关注、分享、点赞、收藏、在看，我是微信公众号「码农先森」作者。
方法--废弃)
)
