大家好，这里是架构资源栈 ！点击上方关注，添加"星标"，一起学习大厂前沿架构！
关注、发送C1即可获取JetBrains全家桶激活工具和码！
在程序员的世界里，总会遇到一些"前人种树"的系统，留下来的代码让人摸不着头脑，仿佛是上个世纪某位不愿透露姓名的程序员半夜梦游时敲下的产物。
小D最近就遇到了这么一个项目：一个全球数百万设备日志的分析系统。看似正经，实则离谱。一开始你以为它只是个普通报表工具，点点按钮选个时间范围，结果打开之后，发现这玩意儿竟然是个------"SQL注入即服务"系统（SQL Injection as a Service，简称SIAAS）！
报表入口只有一个输入框？！
没错，在这个系统的"最新版本"中，开发者取消了所有按钮、下拉框、日期选择器，只留下了一个纯净的文本框：自己写SQL吧，哥！
这个页面几乎毫无防护，整个数据库就这样赤裸裸地暴露在用户面前。你想查啥？写SQL！你想删库？也没人拦你！这种设计让人怀疑开发者是不是搞错了职业跑去做黑客工具平台了。
但当小D翻开Git版本控制的历史，一切变得有迹可循。这套系统，其实是经过了10年的"逐步进化"，一步一步从规范走向失控的。
一切的开始：只是"加个字段"而已
最初，系统还是一个中规中矩的报表页面，有日期范围、有关键词输入，有个"生成"按钮------再正常不过。
第一个需求是"加一个字段"。开发者非常配合，直接在SQL语句里加了个字段，前端也更新了，皆大欢喜。
结果没多久，又有人说要加一个来自别的表的字段。于是开发者加了JOIN语句，但新问题来了：有些数据看不到了，有人抱怨VLOOKUP出错了，还有人嫌字段顺序乱了......最终达成一致：新字段必须放在表格最后，即使它跟"创建时间"关系密切也不能靠前。
报表越来越多，逻辑越来越绕
后来，开发团队加了个报表类型的下拉框。听起来不错，但这意味着：每次业务有新需求，就要加一个新的报表模板。
两份报表、五份报表、十份报表......最终膨胀到了几十个。而且由于命名混乱、字段顺序微调等问题，很多报表其实差不多，但名字完全看不懂。
于是，开发者又"进化"了一下：把报表名字存进数据库里，这样用户可以自己改名。谁曾想，有人直接把报表名改成了空字符串，前端整个炸了。
最后只能祭出"管理员才能改名"的限制。
神秘页面上线："SQL自由查询入口"
某天，一个有"感染力"的员工提出：能不能加个隐藏页面，大家自己写SQL查询更自由？
开发者居然答应了------上线了一个内部可见的"超级管理员页面"，左侧还有预置的常用SQL，点击即执行，简直就是SQL playground。
"保护措施"：只屏蔽关键词
当然也不是完全裸奔，后来有人加了个粗暴的防护逻辑：只要检测到SQL中含有 INSERT、UPDATE 或 CREATE，直接返回 401 拒绝访问。
这说明什么？说明有人已经在偷偷修改数据了......
随着这个"安全机制"的上线，原来的报表页面也彻底被替换成了这个万能的SQL编辑器页面。
慢查询、卡死、LIMIT机制上线
灾难才刚刚开始。有人写了个复杂的JOIN语句，查询执行30秒还没出结果，系统快被拖死。
于是紧急加了个查询超时设置：最开始是30秒，然后迅速变成了30分钟......很快，开发者又想出"LIMIT"策略：查询语句末尾强制追加LIMIT，不写就自动加。
后来更细了：必须出现在最后一个分号前，不然视为非法。
页面上也开始贴出各种"友情提示"：
- ❗ 不要在凌晨备份时间跑查询
- ❗ 不会JOIN就别乱JOIN
- ❗ 请写LIMIT，拜托了 🙏
最后，这个系统落到了我手里......
当小D加入团队时，这个奇葩系统正式归自己维护。
原本打算大改一波，重新做个正常报表组件：日期范围、筛选框、输入框......但看完源码和十年来的JIRA工单后，小D放弃了。
直到某天，一个员工执行了一个 DELETE 命令------以为只删了一条数据，结果系统整体报表全部异常。原来两个表之间没有外键，JOIN逻辑全靠"日期字段相等"。
sql
INNER JOIN table2 t2 ON
DATE(t1.entry_date) = DATE(t2.entry_date)小D只能临时加了一条"假数据"补回去，然后顺便把 DELETE 加入黑名单。
系统总算活过来了。
尾声：我没能拯救它，但我被它"拯救"了
本以为能慢慢改进这套系统，让它走上正轨。但现实往往不是理想主义者的朋友。
午饭回来没多久，两个安全部同事走到小D工位，和气但坚定地说：
"我们要送你离开这栋大楼。"
至于后续是裁员还是系统真的闯了大祸，就请参考《当机器把我开除了》这篇后续故事吧。
小结
这个故事其实揭示了很多老系统常见的"演变病"：
- 每一个看似"临时改动"，最后都成了永久设计；
- 开发者在"响应需求"中逐渐迷失初心；
- 最终系统演变为不可控状态，却没人敢动它。
技术债最怕的不是没还，而是不断加注变成"技术P2P"。这个SQL注入即服务的案例，真是活生生的"黑暗教程"。
本文由博客一文多发平台 OpenWrite 发布！