直接在Schema中设unique: true仅声明唯一性，实际生效需MongoDB索引支持；若未同步创建索引（如未重启服务或未调用syncIndexes），插入重复值不报错；复合唯一索引须用Schema.index()定义，且线上必须错误处理syncIndexes()。
直接在Schema里用unique: true就行，但别只写这一行
加unique: true确实能声明唯一性，但它只是告诉Mongoose“这个字段要唯一”，真正起作用的是MongoDB底层的索引。如果没同步建索引，插入重复值时不会报错，直到你手动运行db.collection.createIndex()或调用Model.syncIndexes()。
常见错误是只改Schema却忘了触发索引创建：
- 开发环境改完Schema后没重启服务（Mongoose默认只在启动时自动创建索引）
- 生产环境没跑
Model.syncIndexes()，导致新字段的unique形同虚设 - 用
dropDatabase()重置后，索引也丢了，得重新同步
index: true和unique: true能一起用吗？能，但有坑
可以同时写index: true和unique: true，Mongoose会合并成一个唯一索引。但注意：如果字段已经是index: true，再加unique: true不会自动升级——必须删掉旧索引再重建。
更稳妥的做法是显式指定索引选项：
new Schema({
email: { type: String, index: { unique: true, sparse: true } }
})
这样能控制sparse行为（允许null/undefined不参与唯一校验），避免因空值导致索引创建失败。
复合唯一索引怎么写？用Schema.index()
单字段唯一好办，多字段组合唯一必须用Schema.index()方法，不能靠字段级配置。
比如要求userId和type组合唯一：
userSchema.index({ userId: 1, type: 1 }, { unique: true })
注意顺序：1表示升序，不影响唯一性但影响查询性能；如果常用type查，把它放前面更高效。另外，复合索引不支持部分字段为null的场景，除非加sparse: true，但此时{ userId: null, type: "a" }和{ userId: null, type: "b" }会被视为不同值，不触发唯一冲突。
索引创建失败时，syncIndexes()会静默吞错
Model.syncIndexes()默认不抛异常，即使索引创建失败（比如字段类型冲突、权限不足），它只返回一个Promise并resolve。必须手动检查返回值或监听index事件：
await User.syncIndexes().catch(err => {
console.error('索引同步失败:', err.message)
})
或者启用调试模式看底层命令：mongoose.set('debug', true)，能看到实际执行的createIndex命令和返回结果。线上环境务必加错误处理，否则唯一约束可能一直没生效，直到某次插入重复数据才暴露问题。
唯一索引不是一劳永逸的开关，它依赖Schema定义、索引同步动作、MongoDB服务状态三者一致。最容易被忽略的是：本地开发改了Schema，测试通过了，但上线后忘了在生产库上跑syncIndexes，结果重复数据悄悄入库。
