三天时间，你用AI工具搭完了一个完整的SaaS雏形。页面切换流畅，按钮反馈及时，登录注册一路通顺，甚至移动端看着也挺像样。你兴奋地把预览链接发给了几个朋友，打算周末就正式上线。可就在发布前夜，你突然想再检查一遍——结果发现API密钥就明晃晃躺在前端代码里，数据库规则基本没设，任何登录用户都能摸到别人的订单。这种事在初学者圈子里，比想象中要常见得多。

AI辅助编程的效率确实让人兴奋。一个不会写后端的前端设计师，一个只是试试水的大学生，一个想验证想法的创业者，现在都能在几天甚至几小时内把想法变成可操作的产品。但“能用”和“能安全用”之间有一条容易被忽略的沟。界面好看、功能跑通，这些都是在明处的反馈；安全问题往往沉默着躲在暗处。直到有人利用了你没注意的漏洞，把测试用的密钥拿去挖矿，或者误删了整个数据库，你才会意识到，当初少看了几个地方。

在真正按下“发布”之前，有五件事值得你花半天逐项复查。它们不是什么高深的安全攻防技术，而是几乎每个初学者都有机会踩进去的坑。

一、查一查API密钥是不是在裸奔

最常出事的，就是直接把密钥写在代码里。你可能觉得“反正就测试两天”，随便粘贴了一个API Key到前端文件中；也可能在GitHub上传项目时忘了把.env文件加进.gitignore，把密钥一起递了出去。AI生成的代码有时候会自动填充示例密钥，或者直接把敏感字符串放进客户端逻辑，因为它当初只是为了让你快速看到效果，并不会主动提醒你这些东西该藏起来。

判断标准很粗暴：凡是浏览器能看到的，用户就能看到。检查一下，所有API密钥是不是都存在环境变量里？前端代码里还会不会出现私密字段？.env文件有没有被Git跟踪？如果代码已经上传到GitHub，有没有不小心把历史记录里的credentials也留下？用一个简单的全局搜索，在项目里扫一遍“key”“secret”“token”这些关键词，经常能发现惊喜。即便是用了Supabase、Firebase这类后端即服务的平台，也要注意，客户端初始化所用的anon key虽然可以公开，但服务权限的service_role密钥必须严加保护，绝不能出现在任何可公开访问的地方。

二、数据库权限是不是给了不该给的人

用了Supabase或Firebase这类工具，很容易产生一种错觉：数据库默认就是安全的。很多初学者以为，只要前端藏好了页面入口，后端数据就不会被随便拿到。但数据库产品本身自有一套访问规则，默认配置可不是“只允许本人操作”，而可能是“允许所有登录用户读取”。这中间的差异，足以让一个好奇的用户翻遍别人的数据。

你需要实际测试下——用一个普通用户身份登录，能不能通过改API请求参数去拉另一个用户的个人信息？数据库的安全规则有没有打开？每张表的读、写权限是不是只开放给匹配的用户ID？那些只有管理员才能调用的操作，是不是真的只能在服务端执行、无法从客户端绕过去？用户数据是产品最核心的资产，一个配置疏忽就可能让信任瞬间崩塌。Supabase有RLS（行级安全策略），Firebase有Firestore规则，它们都不是开了就万事大吉，而是要对应到每一个操作的实际权限模型。

三、登录不是终点，用户能做什么还得继续管

登录只是验证了“你是谁”，而一个真正安全的系统还要控制“你能做什么”。AI快速生成的应用经常能做出完整的登录页面、注册流程、密码找回，甚至连第三方OAuth都集成了，但当不同角色的用户进入系统后，权限边界就开始模糊。

检查一下：普通用户能不能访问管理员的后台界面？一个登录客户能不能通过修改URL参数偷看另一个客户的仪表盘？已经退出登录的用户还能不能直接请求受保护的API接口？如果后台接口只是在前端用一段if语句隐藏了入口，那基本等于没设防。真正有效的权限检查必须落在后端，每一次敏感操作都要重新验证请求者的身份和角色。前端藏着菜单只是为了让界面清爽，绝不是安全措施。

四、应用跑稳了再拿给别人看

安全问题之外，稳定性也同样会在第一印象里丢分。花了那么多心思做出来的应用，如果别人点开就是一片空白，或者提交表单后报了一串英文错误，之前所有投入的价值都会被打折。

发布前至少做一次完整的走查：打开浏览器的开发者工具，看看控制台有没有报红色的错误；所有依赖包是不是都正确安装了，有没有遇到版本冲突；页面之间的跳转有没有404；移动端的布局会不会乱掉，按钮是否好点击；表单在提交时能不能正常收到数据，验证失败时的提示信息有没有不小心把服务器路径或数据库字段名暴露出来。这些细碎的问题虽然不会直接导致数据泄露，但它们是用户感知可靠性的第一道门槛。尤其是错误提示里若含有技术细节，等于给潜在攻击者递上了一张内部结构的名片。

五、别只测“顺利流程”，故意输错才是真检验

初学者的测试路径通常是一条直线：用正确的账号、正确的步骤、正常的数据，一路走到最终页面。但真实用户的行为毫无规矩。他们会在注册时输一个不存在的邮箱格式，会上传一个超大文件，会连点两次支付按钮，会在填写一半时忽然刷新页面，会留下所有必填项然后直接提交。

发布前，你至少要亲自做一些破坏性尝试：用错误的邮箱和密码组合登录，看看应用会不会返回过于具体的提示（比如“该邮箱不存在”就比“账号或密码错误”暴露更多信息）；上传一个10MB甚至更大的文件，测试上传接口有没有做体积限制；在支付或提交按钮上快速点击多次，会不会导致重复下单；输入框里塞进奇怪字符，看会不会引发解析异常。很多时候，AI生成的代码只处理了最标准的情况，对边缘输入完全没有防御。补上这些缺口，不是为了让产品变得迟钝，而是让它在面对不可预测的真实世界时，能够体面地应对，而不是突然崩溃或泄漏信息。

这五个检查点，说到底都指向同一件事：在AI极大压缩了从构思到原型的时间之后，安全与稳定依然是必须由人来做决策的环节。AI不会替你判断密钥该放哪里，不会主动提醒数据库规则可能有漏洞，更不会替你去测试那些毫无章法的用户行为。但好消息是，正因为工具帮你处理了大量重复性工作，你恰好可以把省下来的时间用在这些关键节点上。

你依然可以愉快地享受“想法几小时就变成应用”的时代，只需要在每次兴奋地分享链接前，把这份清单逐项过一遍。这样的习惯一旦建立，你就不只是在“做应用”，而是在交付一个真正为用户负责的产品。