最危险的两行代码是不加 filter 的 deleteMany({}) 和 drop()，必须用显式条件、预检机制、硬编码目标名、事务包装及专用权限账号兜底。
直接结论：不加 filter 的 deleteMany({}) 和 drop() 是脚本里最危险的两行代码，必须用显式条件 + 预检机制兜底。
写脚本前先确认 deleteMany() 的 filter 是否为空
空 filter（如 {} 或 null）等价于“删光所有”，而很多脚本因变量未初始化、配置缺失或逻辑分支遗漏，会意外触发它。
- 检查所有
deleteMany()调用点，确保filter是明确构造的，不是拼接字符串或从用户输入直传 - 在执行前加校验：
if (Object.keys(filter).length === 0) throw new Error("Empty filter rejected"); - 开发环境可强制开启
noCursorTimeout: false并配合explain()预估匹配数：await collection.find(filter).explain("executionStats")，若nReturned过大就中止
drop() 操作必须绑定到具体数据库和集合名，且禁止动态拼接
drop() 不接受 filter，一旦调用即物理清空，且无法通过角色权限限制其执行——只要用户有对应库/集合的 dropCollection 权限，就能删。
- 脚本中禁止出现
db.collection.drop()或db.getSiblingDB(dbName).collection.drop()这类动态调用 - 只允许硬编码目标名，例如：
db.myapp_users.drop()，且该语句需单独封装、加注释并置于独立文件中 - 生产部署前，用
grep -r "drop()" ./scripts/全局扫描，确认无隐藏调用
用事务包装删除操作，但注意它不覆盖 drop()
事务能回滚 deleteOne()/deleteMany()，但对 drop()、dropDatabase() 无效——它们是 DDL 操作，不在事务作用域内。
- 所有删除逻辑优先走
deleteMany()+ 事务，示例：session.withTransaction(() => collection.deleteMany({ status: "archived" })) - 事务内避免混合 DDL 和 DML；如果真要删集合，先 rename 成
mycol_deleted_20260707，观察 24 小时再决定是否真drop() - 注意：事务要求副本集模式，单节点不支持；且超时默认 60 秒，大范围删除需调高
maxTimeMS
连接和权限配置必须与脚本意图严格对齐
脚本跑在哪、连哪个库、用什么账号，三者错配就会让“安全脚本”变成“误删引擎”。
- 连接字符串里的
authSource只管认证位置，不决定权限范围；真正起作用的是创建用户时指定的roles: [{ role: "readWrite", db: "myapp" }] - 脚本应显式指定操作库：
const db = client.db("myapp"); const collection = db.collection("users");，而不是依赖use myapp切库 - CI/CD 中运行脚本时，禁止复用管理员账号；应为每个脚本创建专用账号，例如
cleanup_job，仅授予myapp库的deleteOwn自定义权限（不含dropCollection）
最容易被忽略的是：脚本里写的 db.users 和你连接串里写的 /myapp 没有自动绑定关系，MongoDB 不会帮你做映射。权限、库名、连接参数这三项必须人工对齐，差一个字符就可能删错库。
