你写完一段功能，测试也跑通了，上线后却突然被用户反馈：点个按钮页面直接白屏，或者输入框里输个单引号就报错——这不是玄学，大概率是代码层面的漏洞没修干净。
漏洞不在服务器，就在你刚敲完的那几行里
很多人觉得“漏洞”是黑客的事，跟自己写的业务代码没关系。其实不然。比如一个常见的字符串拼接 SQL：
const sql = 'SELECT * FROM users WHERE name = \'' + userInput + '\'';用户只要输个 O'Reilly，SQL 就崩了；再输个 '; DROP TABLE users; --，数据库都可能被清空。这种不是服务器配置问题，就是你代码里漏掉了参数绑定或转义。
修复不靠运气，靠这几条实操习惯
1. 所有外部输入，一律当“可疑分子”处理。前端传来的、URL 里的、表单填的、甚至你自己存的数据库字段，只要没经过严格校验，就别直接拼进命令、模板或 SQL。
2. 能用参数化，绝不手拼。Node.js 的 mysql2、Python 的 sqlite3、PHP 的 PDO 都支持占位符，像这样：
db.query('SELECT * FROM posts WHERE id = ?', [postId]);3. 模板渲染也要防注入。EJS、Vue、React 默认会转义变量，但如果你用了 <%= rawHtml %> 或 v-html，就得先过一遍 DOMPurify 这类库。
一个真实翻车现场
上周帮朋友看个小后台，登录页有个“记住用户名”功能，把用户名存在 localStorage 里，加载时直接 document.title = localStorage.getItem('user')。结果有人把用户名设成：<img src=x onerror=alert(1)>，一打开页面就弹窗——XSS 漏洞就这么埋进去了。修复很简单：显示前用 textContent 替代 innerHTML，或者用 DOMPurify.sanitize() 过滤。
代码层面的漏洞修复，从来不是等出事了才补，而是写每一行时就想着：“如果用户乱输，这行会不会崩？会不会被利用？”多这一秒的念头，省下的可能是半夜三点的紧急上线。
","seo_title":"代码层面漏洞修复指南｜电脑工场","seo_description":"手把手讲清SQL注入、XSS等常见代码漏洞的修复方法，附真实代码示例和可落地的习惯建议","keywords":"代码层面漏洞修复,SQL注入修复,XSS漏洞修复,代码安全,编程安全"}