GridFS不支持数据库触发器，MongoDB社区版和企业版均无BEFORE/AFTER触发器机制；审计必须在应用层实现，通过封装GridFSBucket、拦截find()等方法并同步写入结构化日志。
GridFS 本身不支持数据库触发器
MongoDB 社区版和企业版均不提供类似关系型数据库的 BEFORE/AFTER INSERT/UPDATE/DELETE 触发器机制，GridFS 更是完全无此能力。所有对 files 和 chunks 集合的写入操作（如 put()、delete()）都绕过任何服务端自动钩子。试图在 secure_files.files 上建触发器来审计文件访问，会直接失败——MongoDB 不识别该语法，驱动也不会执行。
真正可行的审计路径只有应用层拦截
GridFS 的读写必须经由官方驱动（如 mongodb/mongodb PHP 包、pymongo、mongo-go-driver），因此合规审计只能落在调用方代码里。关键不是“怎么让 MongoDB 自己记”，而是“怎么确保每次 find()、openDownloadStream()、delete() 都强制走审计逻辑”：
- 禁止直连
files/chunks集合：所有业务代码不得使用$collection->find()访问 GridFS 元数据，必须封装统一入口 - 封装
GridFSBucket实例：在初始化时注入审计上下文（如当前用户 ID、请求 traceID） - 重写核心方法：例如 Python 中继承
GridFSBucket，覆盖find()和open_download_stream()，在调用父类方法前先写入审计日志到独立集合（如audit_gridfs_access） - 日志字段必须含：
user_id、file_id、operation（"read"/"delete"/"upload"）、timestamp、ip（从请求头提取）
auditLog 配置对 GridFS 操作无效
即使你已启用 MongoDB 全局审计日志（--auditDestination file），它也只记录元数据层面的命令，比如 find 对 secure_files.files 的查询，但不会告诉你这个查询是为了下载哪个文件、由谁发起、是否成功返回了内容块。更关键的是：openDownloadStream() 这类流式读取不触发标准 find 命令，而是在驱动内部分块拉取 chunks，这些操作根本不出现在 audit.json 中。所以依赖 --auditFilter 捕获 GridFS 行为是徒劳的。
权限控制不能替代访问审计
你在 metadata.access_control 里加 user_ids 字段，或给 MongoDB 用户配 read 权限，解决的是“能不能访问”，不是“谁在什么时候访问了什么”。合规审计要求的是可追溯的操作留痕，不是静态权限策略。一个拥有 read 权限的账号批量下载全部文件，系统若无访问日志，就无法定位责任人。真正的落点必须是：每次调用驱动 API 时，同步写一条结构化审计记录，并确保该写入与主操作在同一个事务边界（如用 with_transaction() 包裹）——虽然 GridFS 本身不支持跨 files+chunks 事务，但至少能保证“审计日志写入”和“业务逻辑判断”原子性。
