金融审计日志必须用应用层控制+固定集合+不可变字段实现防篡改，因MongoDB社区版不支持WORM语义；capped collection禁update/delete但会自动淘汰旧文档；audit_logs须含model、model_id、user_id、ip_address、operation、changes、signature等字段并预建索引。
金融交易流水的审计模型不能靠 MongoDB 自身机制“自动防篡改”，必须由应用层控制写入逻辑 + 固定集合（capped collection）+ 不可变字段设计共同实现。社区版 MongoDB 不支持字段级变更审计、不提供 WORM（Write Once Read Many）语义，update 和 delete 操作始终可用——这意味着只要权限放开，日志就能被删改。
为什么不能直接用普通集合存 audit_logs
普通集合允许任意 updateOne、deleteOne，哪怕加了角色权限，DBA 或 root 用户仍可绕过；审计日志一旦被修改或删除，就失去法律效力和监管追溯价值。而金融系统（如《JR/T 0255-2022》）明确要求操作日志“不可覆盖、不可删除、不可篡改”。
固定集合（capped collection）虽不能真正防篡改，但能天然阻止更新和删除：
-
db.audit_logs.updateOne()会直接报错CommandNotSupportedOnCappedCollection -
db.audit_logs.deleteOne()同样失败，且无法建唯一索引，避免误用upsert覆盖旧记录 - 插入性能高、无文档迁移开销，适合高频交易流水场景（如每秒数百笔记账+审计）
- 但注意：它只防“主动删改”，不防“磁盘级覆盖”——当空间满时最老文档会被自动淘汰，这属于设计取舍，不是 bug
audit_logs 文档必须包含哪些不可省略字段
仅记录 model、model_id 和 timestamp 远远不够。监管检查时会重点核验“谁、在什么时间、对哪条记录、做了什么操作、依据什么上下文”。以下字段缺一不可：
-
model: 字符串，如"App\Models\Transaction"，不能硬编码为"transaction"—— 类名才能准确映射到代码和权限策略 -
model_id: 原始 ObjectId（如ObjectId("61a8b3c4e9d2f10012345678")），不是 Eloquent 的id别名；若业务用字符串主键，也必须保持类型一致 -
user_id: 当前操作人 ID，从auth()->id()取，**严禁 fallback 到 0 或 null**；需与统一身份认证系统对齐 -
ip_address: 从request()->ip()获取，代理环境必须解析X-Forwarded-For并做白名单校验，防止伪造 -
operation: 枚举值，如"create"、"update"、"void"（不能只写"save"） -
changes: 字段级 diff 结果，必须排除password_hash、token、updated_at等敏感或元字段；正确做法是缓存retrieved事件时的原始值，再用array_diff_assoc()对比 -
signature: 应用层生成的 HMAC-SHA256 签名，输入含model_id+operation+json_encode(changes)+ 秘钥，存 Base64；用于离线校验是否被篡改
如何让 capped collection 支持高效检索而不牺牲防篡改性
固定集合不支持后台建索引，所有索引必须在创建集合时或首次插入前建好。没索引的 audit_logs 查起来就是全表扫描，等同于没审计。
必须在 db.createCollection() 后立即执行：
db.audit_logs.createIndex({ "model": 1, "model_id": 1, "timestamp": -1 })
db.audit_logs.createIndex({ "user_id": 1, "timestamp": -1 })
db.audit_logs.createIndex({ "operation": 1, "timestamp": -1 })注意：
- 不要建
{ "changes": 1 }这类通配索引——BSON 值过大，会导致索引膨胀甚至失败 - 避免在
changes字段上用$regex查询；真要查某字段变更，应把关键变更项（如status_from、status_to）单独提成顶层字段并建索引 - 如果使用 MongoDB Atlas，可开启
auditAuthorizationSuccess: false记录 authCheck 失败事件，但别开true——性能损耗太大，且与应用层审计重复
金仓数据库兼容模式下怎么复用这套模型
金仓数据库的 MongoDB 兼容模式支持原生 Wire Protocol，insertOne、find、聚合管道都可直通，但它的 capped collection 行为与社区版 MongoDB 不完全一致：
- 创建时必须显式指定
capped: true和size，max参数可能被忽略，以容量为准 - 同样禁止
updateOne和deleteOne，报错信息为OperationNotSupportedOnCappedCollection - 索引创建方式相同，但建议在建库脚本中统一用 SQL 方式预建（如
CREATE INDEX idx_audit_user_time ON audit_logs(user_id, timestamp DESC)），避免驱动差异 - 最大区别在于签名验证：金仓内核不支持应用层 HMAC 内置函数，
signature字段必须由应用计算并校验，不能依赖数据库
真正容易被忽略的是时间精度——金融流水要求毫秒级时序，MongoDB 默认 Date() 只精确到毫秒，但某些驱动（如 PHP MongoDB 扩展旧版本）可能截断为秒；务必在插入前用 new \MongoDB\BSON\UTCDateTime(strtotime('now') * 1000) 显式构造。
