db.changeUserPassword直接覆盖旧密码且无确认机制，仅修改当前数据库中的用户密码，必须在admin库执行并确保已认证，不校验旧密码、不检查强度、不更新其他属性。
db.changeUserPassword 会直接覆盖旧密码，没有确认机制
这个方法不会校验当前密码，调用即生效，一旦输错用户名或新密码，管理员可能立即失访。它只改密码，不更新其他用户属性，也不检查密码强度——哪怕设成 "123" 也能成功。
实操建议：
- 执行前先用
db.getUser("admin")确认用户名拼写和角色是否为"root"或"userAdminAnyDatabase" - 新密码必须用字符串字面量，不能是变量未定义时的
undefined（否则实际设为空密码） - 推荐在
mongosh中操作，避免 shell 脚本里密码明文泄露；若必须脚本化，请用--eval+ 环境变量注入，而非硬编码
必须在 admin 数据库上下文中执行
db.changeUserPassword 不接受数据库参数，它永远作用于当前 db 所指的库。如果误在 test 库下运行，会报错 "UserNotFound: No user found for {user: 'admin', db: 'test'}"，而不是静默失败。
实操建议：
- 连接后第一件事：运行
use admin，再验证db.getName()返回"admin" - 不要依赖连接串里的
?authSource=admin—— 它只影响认证源，不切换当前数据库 - 在副本集或分片集群中，该命令需连到主节点（
rs.isMaster().ismaster === true），否则报"not master"
密码修改后连接会立即中断，需要重连验证
MongoDB 不做会话级密码刷新，客户端持有的旧凭据在下次认证时才暴露问题。常见现象是：命令返回成功，但紧接着 db.runCommand({connectionStatus: 1}) 报 "AuthenticationFailed"。
需要创建、读取、编辑或处理 Word 文档（.docx / .dotx）时使用。触发词：'Word'、'word 文档'、'.docx'、'生成报告'、'制作合同/简历/方案/说明书'、'提取 word 内容'、'在文档里查找替换'、'给文档加页眉页脚/目录/表格'。也用于把任意内容排版成一份正式的 Word 文件。不要用它处理 PDF、Excel 或无关编程任务。中文创作场景尤其适合：小说大纲稿、投稿文档、合同、简历、工作总结。
实操建议：
- 修改后立刻新开一个
mongosh连接测试，命令类似：mongosh "mongodb://admin:newpass@localhost:27017/admin?authMechanism=SCRAM-SHA-256" - 如果使用连接池（如 Node.js 的
mongodb驱动），旧连接会持续报错直到超时或手动关闭；不要等应用自然恢复 - 密码含特殊字符（如
@、/）必须 URL 编码，否则连接串解析失败，错误信息是"InvalidConnectionString"
替代方案：用 db.updateUser 更可控，但要传全量字段
db.changeUserPassword 是快捷方式，本质是 db.updateUser 的简化封装。如果还需同步调整 roles 或 mechanisms，必须用后者，否则原有角色会被清空。
实操建议：
- 仅改密码时，
db.changeUserPassword("admin", "newpass")更简洁；想保留原配置又加权限，改用：db.updateUser("admin", {pwd: "newpass", roles: [{role: "root", db: "admin"}]}) -
db.updateUser要求显式传roles，漏掉就等于重置为[]—— 这是线上事故高发点 - 4.0+ 版本支持
digestPassword: false，但仅限 SCRAM-SHA-1；SHA-256 密码必须由服务端生成，客户端传明文即可
密码本身不加密存储，MongoDB 保存的是 SCRAM 挑战响应所需的哈希值；真正危险的是把密码写进历史命令或日志，mongosh 的 .mongosh_history 默认记录所有输入，记得清空或禁用。
