SQL注入只存在于PHP编写的注中网站中——这句话错得离谱，但它确实曾是存于许多入门教程和论坛老帖里的“常识”。我第一次在真实项目里撞见SQL注入，网站是注中在一个用Java写的政府招标系统上，不是存于PHP。那是网站个阳光刺眼的下午，甲方工程师把后台登录框的注中密码字段原封不动拼进SQL语句，我随手敲了个单引号，存于整个查询直接报错炸出堆栈信息，网站数据库类型、注中表结构全暴露了。存于那一刻我意识到，网站问题从来不在语言，注中而在写代码的存于人。

把SQL注入和PHP绑在一起，网站主要怪早年互联网的“草莽时代”。2000年前后，PHP几乎统治了动态网站，论坛、CMS、留言板全是它写的。那时候没有框架，没有ORM，新手拿到教程就照着拼字符串：SELECT * FROM users WHERE name='$_POST['user']'。这种代码在当时的PHP教程里比比皆是，于是SQL注入的经典案例全拿PHP当主角。可你要是翻翻OWASP的漏洞数据库，用ASP.NET、Python、Ruby甚至Node.js写的注入漏洞一抓一大把。语言本身没有原罪，是“把用户输入直接拼进SQL”这个坏习惯有罪。

我见过最讽刺的一个案例，是个用Python Django写的内部工具。Django的ORM理论上能防注入，但开发图省事，用cursor.execute()执行原生SQL，还偷懒用百分号格式化字符串。结果呢？一个分页参数没做过滤，攻击者构造了?page=1; DROP TABLE logs--，直接把日志表清空了。那哥们儿事后在群里哀嚎，说“我用的Django啊，怎么可能被注入”。你看，工具再好，也架不住人非要走捷径。

再说说Java。Java的JDBC确实提供了PreparedStatement，参数化查询能有效防注入。但现实是，很多老项目里依然躺着大量拼接SQL的代码，尤其是一些急着上线的报表系统。有个金融公司做对账模块，开发把日期范围直接拼进查询，结果被人在日期参数里塞了OR 1=1，把整张交易表全拉出来了。后来审计报告里写着“系统采用Java技术栈，未发现PHP相关风险”，我看了差点笑出声——风险不在语言，在人的惰性和侥幸心理。

真正该背锅的，是“信任用户输入”的思维模式。任何语言，任何框架，只要允许开发者把外部数据当成代码的一部分去解释，注入就有生存土壤。PHP只是恰好在那个年代传播最广，成了替罪羊。现在的PHP也早不是当年的模样，PHP 8的PDO默认就是预处理，Laravel、Symfony这些框架把安全边界焊得死死的。反过来，你用PHP写个mysql_query("SELECT...".$_GET['id'])照样能被打穿——但那是人的问题，不是PHP的问题。

我写代码这些年，最深的体会是：安全漏洞从来不是技术选型的锅，而是决策链上每个环节的疏忽。你选PHP、选Java、选Go，都只是个容器，里面装的是认真还是敷衍，最终决定网站是铜墙铁壁还是纸糊的灯笼。别再把SQL注入的帽子扣在PHP头上了，它冤得很。真要防注入，把参数化查询焊死在代码规范里，比纠结用什么语言管用一万倍。