我写过一个cgi工具，用perl，就一个文件，三百多行。它能从网页表单接收数据，存进sqlite，再生成一个简单的列表页面。这玩意儿放在2024年看，土得掉渣。但当年它救了我的命——客户要一个内部报价系统，预算只够买台二手服务器，连数据库都不给装。
cgi的全称是common gateway interface，通用网关接口。说白了，就是让网页能跟服务器上的程序说句话。现在的人用fastapi、用node.js，大概很难理解为什么有人愿意碰cgi。可cgi有个好处，它不挑语言。python能写，perl能写，连shell脚本都行。你只要保证可执行文件能输出http头，再输出一段html，浏览器就认。
我那个工具的第一版，其实是个玩具。表单提交后，程序把数据拼成一行，追加到文本文件末尾。后来数据多了，文本文件打开都卡，才换了sqlite。换数据库的过程让我明白一件事：cgi工具的核心不在技术选型，而在“请求-响应”这个模型的简单直接。每次请求都重新启动一个进程，听起来浪费，可也意味着没有内存泄漏，没有常驻进程崩溃。crash了？下次请求自动恢复。
有个细节我一直记得。服务器在机房，风扇声很大。我ssh上去改cgi脚本，改错了，浏览器直接显示500错误。那时候没有debug工具，就靠print语句往错误日志里写东西。改一次，刷新一次页面，再去看日志。这种原始的工作流，效率不高，但每一步都踏实。不像现在，框架报错信息堆成山，反而让人不知道从哪查起。
后来我见过一个老运维，用cgi写了个监控页面。他没用任何图表库，就是用gif图片动态生成——每个监控项对应一个像素点，绿色正常，红色告警。整页刷新，图片重新生成。那页面丑得离谱，但三秒一刷，服务器状态一目了然。他说，图表库太花哨，他要的就是“看一眼就知道有没有事”。
cgi工具的真正价值，可能就在于这种“够用就好”的务实。它不追求并发，不追求异步，甚至不追求美观。它只做一件事：把输入变成输出，把流程固定下来。很多内部工具，其实只需要这个程度。你给它一个表单，它给你一个结果，中间的逻辑简单到可以写进注释里。
当然，cgi也有让人抓狂的时候。环境变量传递、中文编码、路径转义，每个坑我都踩过。尤其是编码，当时网页是gb2312，程序输出utf-8，浏览器乱码成一团。最后解决办法很粗暴：在html的meta标签里强制指定charset，程序内部统一用utf-8，外部输入全部转码。丑，但管用。
那个报价系统跑了四年，直到客户换了erp才退役。退役那天，我把它打包存了个tar.gz，放在硬盘角落。偶尔翻到，会想起那段写代码不需要考虑容器、编排、链路追踪的日子。cgi工具就像一把瑞士军刀，不华丽，但关键时刻掏出来就能用。现在工具链越来越重，有时候反而怀念那种“一个脚本解决问题”的干脆。
如果你要处理的任务是内部的、低频的、逻辑固定的，不妨试试cgi。别管什么微服务，别管什么serverless，就一个可执行文件，配一个web服务器，搞定。你甚至不需要框架——框架本身就是一种负担。cgi工具教会我的，是先把问题看透，再决定要不要拿起那把最重的锤子。