根本原因是开发者将不可信的用户输入当作可信指令处理，如直接拼接SQL、用eval执行用户数据、未经校验include文件等；高危行为包括动态函数执行、命令拼接、远程文件包含及反序列化漏洞；修复需建立默认信任外部输入为恶意的防御习惯。
因为PHP代码被注入，根本原因不是语言本身有问题，而是开发者在处理用户输入时放松了警惕——把不可信的数据当成了可信指令。
所有注入漏洞的起点，都是“信任了不该信任的东西”
比如直接把$_GET['id']拼进SQL语句、用eval($_POST['code'])执行用户发来的字符串、或把$_GET['page']不经检查就include()进来。这些操作看似方便，实则等于把服务器的控制权交到攻击者手上。
常见高危行为直接打开注入大门
- 使用
eval()、assert()、create_function()执行动态字符串 - 用
system()、exec()、shell_exec()拼接用户输入执行命令 -
include()或require()直接加载$_GET或$_POST传入的文件名 - SQL查询中用字符串拼接代替预处理语句
- 反序列化未经校验的用户数据（如
unserialize($_COOKIE['data'])）
环境配置不当会放大风险
-
php.ini中未禁用危险函数（disable_functions = eval,exec,system,passthru,shell_exec） -
allow_url_include = On，导致远程文件包含成为可能 -
display_errors = On在生产环境开启，泄露路径、类名、数据库结构等关键信息
修复不等于打补丁，而是建立防御习惯
立即学习“PHP免费学习笔记（深入）”；
- 所有外部输入（GET/POST/COOKIE/FILE/HTTP头）默认视为恶意，先验证再使用
- 优先用白名单：只允许
['list','detail','export']，其他一律拒绝 - 数值型参数强制转整型（
intval()）或用类型声明（function get($id): int） - 字符串输出到HTML前必过
htmlspecialchars()，入库前走预处理语句 - 关键操作日志留痕，异常请求自动告警，而不是静默失败
本质上，PHP不会主动注入自己，是人让代码走上了那条危险的路。
