commonjs仅是node.js模块规范，不提供安全审计或日志能力；真实审计需在express/koa中间件中主动集成，涵盖请求响应拦截、敏感字段过滤、结构化日志（含timestamp、reqid、userid、operation、status、elapsedms）、脱敏处理、权限前置校验及持久化存储。
CommonJS 本身不提供安全审计或日志记录能力，它只是 Node.js 的模块加载规范。真正的安全审计与日志记录需要你在中间件模块中主动设计和集成——关键在于“谁调用、调了什么、传了什么、结果如何”，以及“如何防止敏感信息泄露、如何防篡改、如何留痕可追溯”。
中间件中统一拦截请求与响应
在 Express/Koa 等框架的 CommonJS 中间件里，应尽早捕获原始请求数据（method、url、headers、body）和响应状态（status、duration），但注意：不要直接记录 password、token、银行卡等字段。
- 使用 req.ip 和 req.get('User-Agent') 记录来源，避免依赖不可信的 X-Forwarded-For
- 对 req.body 和 req.query 做白名单过滤，例如只记录
email、action，忽略password、api_key - 用 on-finished 或 res.on('finish', ...) 钩子确保响应结束时才写日志，避免流式响应未完成就记录
审计日志需结构化且防篡改
日志不是随便 console.log，而是要能回溯操作人、时间、资源、结果，并支持后续分析。推荐用 JSON 格式写入文件或转发到日志服务（如 Winston + File Transport / Elasticsearch）。
- 每条审计日志至少包含：timestamp、reqId（全局唯一请求 ID）、userId（若已认证）、operation（如 'update_user'）、resource（如 '/api/users/123'）、status（200/403/500）、elapsedMs
- 敏感操作（如删除、权限变更）建议额外记录 before 和 after 快照（脱敏后），比如用户角色变更前是 ['user']，变更是 ['admin']
- 日志文件启用 chmod 600，避免非 root 进程读取；生产环境禁用
console.log，全部走日志库
安全上下文与权限校验必须前置
审计的前提是知道“谁在做什么”。中间件应在日志记录前完成身份识别与权限判定，否则日志里的 userId 可能为空或伪造。
- JWT 解析后验证 exp、iss、signature，并从中提取
sub或uid作为 userId，而非信任客户端传来的任何字段 - 权限检查失败时，仍要记录审计日志（例如 status: 403, operation: 'delete_post', reason: 'insufficient_role'），这是安全事件的关键线索
- 避免在日志中拼接用户输入（如
logger.info(`User ${req.query.id} accessed...`)），防止日志注入，一律用结构化字段传参
避免常见陷阱
很多团队的日志看似完整，实则无法用于真实审计——要么信息缺失，要么格式混乱，要么根本没留存。
- 不要把日志写在内存或临时变量里；必须持久化到磁盘或远程服务，且保留至少 90 天（合规要求）
- 禁止在日志中记录明文密码、密钥、OAuth refresh_token、身份证号等 PII 数据；可用哈希（如 sha256）或掩码（如
***@gmail.com）替代 - 异步操作（如数据库查询）出错时，确保错误对象被序列化为字符串再写入日志，避免
[object Object]占位
不复杂但容易忽略——安全审计不是加个 logger 就完事，而是围绕“可信输入、明确主体、结构输出、防丢防泄”四点，在每个中间件环节做克制而精准的设计。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
