安全与合规：上线前的安全自查与备案

你的产品做完了、测过了、准备上线。激动之余，有个问题你可能一直没敢细想：AI 帮你写的这堆代码，安全吗？ AI 很会让功能「跑起来」，但它默认追求的是「能用」，不是「安全」——它可能把密钥直接写进代码、可能拼出一条能被注入的数据库查询、可能写了个「改个 ID 就能看别人数据」的接口，偏偏看起来一切正常。带着这些洞上线，不是「会不会出事」的问题，是「什么时候被人发现」的问题。 这一节就带你在上线前，把最该堵的几个洞过一遍，再把国内绕不开的备案这件事讲清楚。

这篇适合谁：你已经能用 AI 做出完整产品、能部署、有后端和用户系统，正准备正式上线。读完你会有一张能照着打勾的安全自查清单，认得几类最高频、最致命的漏洞长什么样，也知道国内上线在合规上有哪些硬门槛绕不过去。

重要提醒：安全与合规涉及法律法规和监管规则，本文只讲通用的工程自查方法和方向，不构成任何法律或合规承诺；备案、隐私政策、个人信息保护等具体要求，以官方与专业人士为准、规则会变。 真要正式商用，务必咨询专业人士、以监管部门最新规定为准。

---

为什么 AI 写的代码尤其要 review 安全

这不是抹黑 AI，是它的工作方式决定的。你让 AI「做个能登录、能看订单的功能」，它会给你一段功能上正确的代码——但安全是「不写就默认没有」的东西，你不特意要求，它往往不会主动加。几个典型：

• 你说「连数据库查这个用户的数据」，它可能直接把变量拼进 SQL 语句里——功能能跑，但留下了注入口子。
• 你说「调这个 API」，它可能把 API 密钥直接写进代码——能跑，但密钥跟着代码进了 git。
• 你说「做个查看订单的接口」，它可能只校验了「登录没」，没校验「这单是不是他的」——能跑，但能越权。

所以铁律是：凡是涉及数据库查询、密钥、用户权限、用户输入的代码，AI 写完你都要专门盯一眼安全。 你甚至可以反过来用 AI：把代码贴回去，明确问它「这段有没有 SQL 注入 / 越权 / 密钥泄露的风险？」让它自查一遍——但最终拍板的得是看懂了的你。

---

上线前最该堵的几个洞

下面这几类，是个人产品上线翻车的高频区。一个个看懂它长什么样、怎么堵。

密钥泄露：最常见、最致命

API 密钥、数据库密码、支付商户密钥、各种 token——这些一旦泄露，等于把你家钥匙挂在门外。 最常见的泄露途径就两条：

• 硬编码进代码，跟着 git 推到了公开仓库：哪怕你后来删了，git 历史里还在，爬虫几分钟就能扫到。
• 写进了前端代码：前端代码用户在浏览器里随便就能看，任何放进前端的密钥都等于公开。

堵法：所有密钥放服务器端环境变量，绝不硬编码、绝不进前端、绝不提交 git；用 .gitignore 排除 .env 之类的文件；万一已经推上去了，第一时间去对应平台作废旧密钥换新的——删 git 记录没用，密钥已经漏了，只有换掉才安全。

注入（SQL 注入等）：别让用户输入变成命令

当你把用户输入直接拼进数据库查询语句时，坏人就能在输入框里填一段「精心构造的内容」，让它从「数据」变成「命令」，从而拖走你整张表、甚至删库。这就是 SQL 注入。

堵法：永远用「参数化查询 / 预编译语句」，把用户输入当「数据」传给数据库，而不是拼成「语句」。 现代的数据库库和 ORM 默认就是参数化的，只要你别图省事手动拼字符串，注入基本就堵死了。看到 AI 写的代码里有「把变量直接拼进 SQL 字符串」，立刻改成参数化。

越权：改个 ID 就能看别人的东西

前面用户系统那节讲过，这里再强调，因为它太常见了：只校验「登录没」，不校验「这条具体资源是不是他的」，用户把 URL 或请求里的 ID 一改，就看到了别人的数据。堵法就一句：每次访问具体资源，都校验它属不属于当前用户。

XSS（跨站脚本）：别让用户输入变成网页脚本

如果你把用户填的内容原样显示在页面上（比如评论、昵称、留言），坏人可以填一段脚本，当别的用户打开这个页面时，脚本就在他们浏览器里执行了——能偷登录凭证、能冒充操作。这叫 XSS。

堵法：对要显示在页面上的用户输入做转义/过滤，让脚本变成纯文本显示而不被执行。多数现代前端框架（React/Vue 等）默认会转义，所以一般安全；危险的是你手动拼 HTML、或用了「直接渲染原始 HTML」的那类 API（如 dangerouslySetInnerHTML），这些地方要格外当心。

不信前端输入：所有校验后端必须再来一遍

这是贯穿前面所有点的总原则：前端的任何东西——金额、ID、权限、表单校验——都能被用户绕过或伪造，所以后端必须把每一项重新校验一遍。 前端的校验只是为了体验（让用户少填错），真正的防线永远在后端。AI 写代码时很容易「前端校验了就算数」，你要补上后端这一道。

---

增量一：上线前安全自查 checklist

正式上线前，对着逐条打勾。一条没过，就别急着上：

• 密钥全在环境变量，没有任何密钥硬编码在代码里、没有写进前端、没提交进 git
• .gitignore 排除了 .env 等敏感文件，翻一遍 git 历史确认没漏推过密钥
• 数据库查询全部参数化，没有「把用户输入手动拼进 SQL」的地方
• 每个受保护接口都校验身份，每次访问具体资源都校验归属（防越权）
• 用户输入显示前做了转义，没有不受控地渲染原始 HTML（防 XSS）
• 所有关键校验后端都做了一遍，不依赖前端校验（金额、ID、权限尤其）
• 全站强制 HTTPS，没有明文 HTTP 传输敏感信息
• 有隐私政策和用户协议，说清收集什么数据、怎么用
• 国内服务器/域名已备案（见下文），未备案别对国内开放
• 关键接口有基本的限流/防刷，别让人无限次调（防被刷爆、被撞库）
• AI 写的涉及数据库/密钥/权限/输入的代码，都专门 review 过安全

---

增量二：高频漏洞速查表

漏洞	它长什么样	怎么堵
密钥泄露	密钥硬编码、进了前端、推进了 git	放环境变量；已泄露立刻去平台作废换新；.gitignore 排除 .env
SQL 注入	用户输入被直接拼进查询语句	用参数化查询/ORM，把输入当数据不当命令
越权	只验登录没验归属，改 ID 看别人数据	每次访问资源校验「是不是当前用户的」
XSS	用户输入原样渲染成网页，脚本被执行	显示前转义；慎用渲染原始 HTML 的 API
信任前端	金额/权限/校验只在前端做	后端把每项关键校验重做一遍
接口被刷	没限流，被人无限次调用	给关键接口加限流、验证码、防刷机制
明文传输	用 HTTP 传密码/隐私	全站强制 HTTPS

想系统了解通用 Web 安全风险清单，可参考 OWASP Top 10 这类公开资料；具体到你的产品和所在地区的合规要求，以官方与专业人士为准、规则会变。

---

合规：国内备案是硬要求，隐私政策别省

技术漏洞之外，上线还有一道合规门槛，国内尤其绕不过去。

服务器 / 域名备案

在中国大陆境内的服务器上对外提供网站服务，域名必须先完成备案（ICP 备案），这是法定要求，不是可选项。 没备案的域名解析到大陆服务器，会被拦截、打不开。基本认知：

• 备案一般通过你买服务器的云厂商（阿里云/腾讯云等）发起，由它们协助提交到主管部门；
• 备案需要主体信息（个人或企业）、域名、服务器等材料，审核需要时间，要预留出来，别等上线当天才办；
• 如果业务涉及经营性内容，可能还需要经营性 ICP 许可证等额外资质。

备案的具体材料、流程、时长、以及不同业务类型要不要额外许可，都以工信部及你所用云厂商的官方说明为准、规则会变。 把服务器放在境外可以绕开大陆备案，但要面对访问速度、政策合规、跨境数据等另一套问题——出海这条线，前面出海篇有展开。

隐私政策与用户协议

只要你的产品收集用户信息（注册邮箱、手机号、行为数据都算），就该有：

• 隐私政策：说清你收集什么、为什么收、怎么存、会不会给第三方。
• 用户协议：说清双方的权利义务、免责、使用规则。

这不只是「显得正规」——个人信息保护是有法律约束的，收集用户数据却不告知、不合规处理，是会担责的。 别裸奔上线。具体该写哪些条款、满足哪些个人信息保护要求，以官方与专业人士为准、规则会变，正式商用建议请专业人士把关。

---

故障复盘：两个真实会发生的事故

事故一：密钥进了 git

经过：图省事把某个 API 密钥直接写进代码，推到了公开仓库。没几天，账单异常——密钥被爬虫扫到，有人拿去疯狂调用，产生了一大笔费用。

为什么会这样：公开仓库被全网扫描，硬编码的密钥几分钟内就会被发现；删代码没用，git 历史里还在。

正确处置：第一时间去平台作废这个密钥、重新生成（这是唯一有效的止血）；把密钥改放环境变量；.gitignore 排除敏感文件。记住：密钥一旦进过公开 git，就当它已经泄露，只有换掉才安全。

事故二：接口被刷爆

经过：一个发短信验证码 / 调用付费 AI 的接口没做任何限流，被人写脚本无限次调用，要么把你的短信额度刷光、要么把 API 账单刷爆。

为什么会这样：公开接口默认就是「谁都能调、想调多少次都行」，不加限流就是敞着的水龙头。

正确处置：给这类会花钱、会发消息、会写数据的关键接口加限流、加验证码、加防刷；监控调用量，异常就告警。上线前就该问一句：我这接口要是被人一秒调一千次，会发生什么？

---

动手挑战

挑一个做了才算数：

1. 拿你的项目，对着上面那张安全自查 checklist 从头到尾打一遍勾。把没过的那几条列出来，一条条补上再上线。
2. 翻一遍你的 git 历史和前端代码，专门找有没有任何密钥（搜 key、token、secret、password 这类词）。但凡找到一个硬编码的，立刻去平台作废换新，再改成环境变量。
3. 进阶：把你 AI 写的、涉及数据库查询和用户权限的那几段代码，贴回 AI 并明确问它「这段有没有 SQL 注入、越权、XSS 的风险？逐条指出来」，看它能挑出什么，再自己判断要不要改。

---

小结 · 你现在掌握了什么

• 你明白了 AI 写的代码「能跑」不等于「安全」，凡涉及数据库、密钥、权限、用户输入的地方，都要专门 review 安全。
• 你认得了几类最高频致命的漏洞——密钥泄露、SQL 注入、越权、XSS、信任前端，知道每一类怎么堵，手里有一张能打勾的自查 checklist 和速查表。
• 你知道了国内上线的合规硬门槛：服务器/域名必须备案、收集用户信息要有隐私政策和用户协议，并清楚这些都以官方与专业人士为准、规则会变，正式商用要请专业人士把关。

安全和合规是上线前最没存在感、却最不能省的一关——它平时看不见，出事时能要了产品的命。带病上线的代价，远比上线前花半天打一遍勾要大得多。把这道关过了，你的产品才算真正可以放心交给用户。

下一步：上线之后，产品就进入了「运营」阶段——怎么让人找到你、怎么把用户留下来，是另一段旅程，本站「数字员工」「组织管理」两个支柱和运营相关的内容都能接上；想看自己在整条编程路上走到了哪、下一步往哪走，对照三支柱路线图，或回到 AI 编程教程大全系统补课。

👉 看看我们的 AI 编程实战体系课，或逛 AI 编程教程大全 把基本功打扎实。