审计链路不是简单地“把日志保存下来”，而是让一次关键业务操作能够被完整还原：谁在什么时间、通过什么身份和终端、对什么对象执行了什么动作，系统依据何种规则作出响应，最终产生了哪些数据变化。设计目标应集中在真实性、完整性、可追溯性和责任可认定性，而不是日志数量。
先定义审计事件
每一条审计记录都应围绕业务动作建模，而非只记录接口访问。建议至少包含操作者身份、租户或组织范围、操作对象、动作类型、操作前后关键值、结果状态、失败原因、请求关联标识和时间信息。涉及审批、权限变更、数据导出、删除、支付或配置调整时，还应记录触发来源、审批依据和影响范围。
业务审计日志与运行日志必须分离。运行日志用于排查异常，审计日志用于证明事实；前者可以按运维需要清理，后者则应依据业务和合规要求保留，避免因技术日志轮转导致关键证据缺失。
让链路跨越系统边界
审计信息应从用户界面一路贯穿到后端服务、数据访问和外部接口。前端只负责提交必要上下文，真正的操作者身份、权限判断和结果状态必须由服务端确认，不能信任客户端传入的用户标识。多服务调用时，应沿用统一的请求关联标识，使一次操作能够串联起鉴权、业务处理、数据变更和异步任务。
对于批量导入、自动任务和接口调用，操作者不能只写成“系统”。应区分真实发起人、执行主体和调用来源；当权限代理或定时任务执行时，既要记录执行账户，也要保留原始触发者。
重点防止事后篡改
审计存储应与业务数据库的写权限隔离，普通业务账号不应具备修改或删除审计记录的能力。敏感数据可采用加密存储，传输过程使用 HTTPS，并结合访问控制、WAF 和 OWASP 安全防护思路降低暴露风险。对高风险场景，还应增加写入后的完整性校验、只读归档和独立备份，并记录每次查阅、导出及管理操作。
审计链路的验收不能只看“有没有日志”，还要验证失败操作是否留痕、权限拒绝是否可定位、数据变更能否还原、跨服务记录能否关联，以及日志本身是否存在越权访问和删除路径。只有把事件模型、身份体系、关联机制、存储隔离和审计查询一起设计，日志才会从排错工具变成可用于追责、风控与合规的证据链。
