云开发数据库API不触发SQL注入，因其基于JSON条件抽象、由腾讯云统一解析，不暴露SQL解析器；但直连自建库、字符串拼接查询、未校验用户输入等操作会重新引入风险。
微信小程序后台用云开发（CloudBase）时，db.collection().where() 等 API 本身不拼接 SQL，天然规避了传统 SQL 注入风险——但前提是，你没绕过它去手写 SQL 或直连自建数据库。
为什么云开发数据库 API 不会触发 SQL 注入
云开发的 db SDK 是面向文档的操作抽象，所有查询都通过 JSON 结构描述条件，例如：
db.collection('users').where({
username: _.eq('admin'),
status: _.gt(0)
}).get()
这类调用最终由腾讯云侧统一解析为安全的底层查询指令，不经过用户可控的 SQL 字符串拼接环节。数据库层不暴露 SQL 解析器给前端或云函数逻辑，也就没有“注入点”可利用。
常见误解是把“输入校验缺失”等同于“SQL 注入”，其实二者风险性质不同：前者可能导致业务逻辑错乱或越权读取，后者是直接执行任意数据库命令。云开发切断了后者的链路。
哪些操作会重新引入 SQL 注入风险
一旦脱离云开发原生 API，风险就回来了。以下行为必须避免：
- 在云函数中使用
mysql2、pg等驱动直连 MySQL/PostgreSQL，并用字符串模板拼接用户输入，例如：query(`SELECT * FROM users WHERE id = ${event.id}`) - 调用自建后端接口时，把小程序传来的
id、sort、keyword参数未经清洗就透传给后端 SQL 查询 - 在云函数里解析用户传入的 JSON 条件后，错误地转成原始 SQL 字符串，比如把
{ field: 'name', value: "'; DROP TABLE users; --" }直接塞进WHERE ${field} = '${value}' - 用
eval()或new Function()动态执行用户控制的查询逻辑（极罕见但存在）
云开发下仍需防范的真实攻击面
虽然 SQL 注入没了，但攻击者会转向其他路径：
将产业文章整理为适合微信公众号/服务号发布的研究型草稿，支持原文读取、分层摘要、产业链标的梳理、image2 海报与封面生成、正文排版、微信草稿保存、回读校验和发布前确认。适用于鹊桥产业等服务号的半导体、AI 算力、先进封装、光通信、新能源、机器人等产业链研究内容。
— where() 条件未鉴权：比如用户传 { openid: 'other_user_openid' } 查询他人数据，后端没校验 openid === event.userInfo.openid，导致平行越权
— orderBy() 字段可控：若允许用户指定排序字段名（如 event.sortBy = 'status; DROP TABLE logs;'），而代码又未白名单过滤，可能触发服务端异常或信息泄露
— limit() 和 skip() 被滥用：配合无分页限制的查询，可能被用于暴力遍历全量数据
— 云函数未启用登录态校验：event.userInfo 可被伪造（若未开启「强制校验」开关），导致身份冒用
关键检查点：三处必须加的防护
云开发不是免检金牌，这几个地方漏掉一个，就等于把门虚掩：
- 所有云函数入口第一行加
if (!event.userInfo?.openid) return { err: 'unauthorized' };，并确认云开发控制台已开启「登录态校验」 - 对
where()中的字段值做最小范围约束，例如手机号用/.{11}/校验，ID 用/^[a-f\d]{24}$/（MongoDB ObjectId） - 禁止将用户输入直接作为
orderBy()的字段名；必须走白名单映射：const validSort = { time: 'created_at', score: 'score' }; const sortField = validSort[event.sort] || 'created_at';
真正危险的从来不是“会不会被注入”，而是“有没有假设用户输入是可信的”。云开发帮你挡掉了 SQL 层的子弹，但业务逻辑层的漏洞，还得一行代码一行代码去堵。
