内容摘要：有个朋友上周发来一个压缩包，文件名是“chatgptphp源码”。他问这玩意儿能不能直接部署到他的小服务器上，用来接点私活。我解压看了一眼，里面躺着一个PHP文件，大概两千行，外加一个SQL导入脚本。

有个朋友上周发来一个压缩包，源码文件名是源码“chatgptphp源码”。他问这玩意儿能不能直接部署到他的源码小服务器上，用来接点私活。源码我解压看了一眼，源码里面躺着一个PHP文件，源码大概两千行，源码外加一个SQL导入脚本。源码说实话，源码第一反应是源码想笑——这年头还有人用PHP写ChatGPT接口？但仔细翻了翻，发现这事儿比想象中有意思。源码

这套源码的源码核心逻辑很简单：用PHP的cURL库去调OpenAI的API，然后通过Session存对话历史。源码它没有用任何框架，源码连Composer依赖都没装，源码纯手写。代码风格很老派，变量命名是$a、$b、$msg这种，注释倒是写得挺全，中文注释，一看就是国内开发者干的活。最让我意外的是，它居然实现了流式输出——用的不是WebSocket，而是最原始的ob_flush()和flush()函数，把GPT的回复一段段往浏览器推。这个技巧我在2015年做聊天室的时候用过，没想到2024年还有人记得。

部署过程确实简单。把文件丢到Apache的www目录，改一下config.php里的API Key，导入数据库，打开index.php就能聊。整个流程五分钟搞定。但问题也出在这儿——这代码压根没考虑并发。每个人共用同一个Session文件，聊两句就互相串台。我试着开了两个浏览器窗口测试，A窗口问“今天天气”，B窗口答“我在思考人生”。朋友说客户只要演示用，不追求多完美，我也就没再多嘴。

真正让我感慨的是这行代码：$response = file_get_contents("php://input");。它把整个请求体当成字符串处理，然后json_decode。如果用户传了超大文本，PHP的内存限制直接爆掉。但换个角度想，这恰恰说明作者是个实用主义者——能用就行，管他什么最佳实践。这让我想起十年前做外包项目时，为了赶工期，经常在控制器里直接写SQL查询。那时候觉得丑陋，现在反而觉得有种粗糙的生命力。

这套源码里还有个细节挺逗。它内置了一个“敏感词过滤”函数，用的是数组遍历加str_replace替换。词库大概五十来个词，全是政治敏感和脏话。但OpenAI的API本身就有内容审核，这套过滤纯属多此一举。不过想想也合理——国内服务器上跑这玩意儿，万一被查到没做过滤，麻烦的是自己。所以这层薄薄的防护网，与其说是技术需求，不如说是心理安慰。

用下来最大的感受是：这套代码的价值不在代码本身，而在于它证明了PHP依然能干这活儿。现在主流方案是Python加FastAPI加SSE，或者Node.js的流式转发。PHP在AI应用领域几乎被遗忘了，但它跑在几乎所有的虚拟主机上，不需要装Python环境，不需要配置Nginx反向代理，连宝塔面板都不用动。对于只买得起共享主机的个人站长来说，这是唯一的入口。

我最后给朋友的回复是：能用，但别指望它扛住十个以上并发。他问我能不能改成Redis存Session，我说可以，但你得先装Redis扩展。他沉默了一会儿，说那还是算了，演示完就关掉。这大概就是PHP生态的现状——老技术还在发挥余热，但新业务已经懒得等它了。不过说实话，看着那两千行代码里偶尔冒出来的“// 这里要优化”的注释，我倒是觉得，这比那些用人工智能生成的花架子代码有人味儿多了。