服务端日志Server Logs
你可能会说
线上报错了，我想知道服务器那边到底发生了什么，去哪看？
记录后端运行时发生了什么，主要用来查找失败原因例如用户提交订单时出现服务器错误；如果记录了关键步骤，日志可以帮助判断是保存数据还是检查权限出了问题。日志要保留时间和必要线索，但不能记录密码、登录凭证或完整个人资料。
你可以这样告诉 AI Agent
请为订单接口补充结构化服务端日志：时间、级别、request ID、订单引用、动作、耗时和错误堆栈。密码、Token、Cookie 和完整个人资料必须脱敏；复现后用 request ID 串起整条请求。
什么时候用
- 记录时间、级别、请求 id、动作、结果和耗时一条可定位的日志12:08:31 INFO req_8fa2POST /api/orders · 201 · 184ms
- 错误日志保留堆栈和必要上下文，用户响应保持简洁用户和开发者看到不同层次页面提示暂时无法保存，请重试服务端日志DB timeout · stack trace
- 部署后先复现一次，再按时间或 request id 搜索日志用 request id 串起一次请求req_8fa2 · request receivedreq_8fa2 · payment checkedreq_8fa2 · order created
- 对错误率、延迟和关键失败设置监控与告警从单条日志上升到监控过去 5 分钟错误率 8.2%告警已通知值班人员
什么时候不用
- 打印密码、Token、Cookie 或整份用户资料日志中不能记录敏感信息password=123456token=eyJhbGciOi••••cookie=session=••••
- 只写“出错了”：没有动作、对象和错误原因这条日志无法帮助排错16:42:09 ERROR 出错了缺少请求、动作、对象和原因
- 用日志代替错误处理：打印后仍假装请求成功打印错误后仍返回成功数据库失败→console.error→200 OK日志不能代替重试、回滚或失败响应
- 线上开启海量调试日志又从不清理，成本和噪音一起涨调试日志淹没真正的问题每天1,280 万行 DEBUG真正错误3 行，被噪音盖住
组成结构 · Anatomy
12:08:31 · INFOreq_8fa2order created · 184ms
说明何时发生、是普通信息、警告还是错误
把同一次请求产生的多行日志串在一起，方便跨步骤追踪
记录动作、结果、耗时和必要标识，但不写密码、Token 或完整个人资料
常见变体 · Variants
INFOINFO
请求完成 · 201
记录正常的关键业务动作
WARNWARN
重试第 2 次
暂未失败，但需要关注
ERRORERROR
数据库连接失败
请求失败，需要定位和告警
典型使用场景
Vercel Function Logs
函数日志查看一次请求发生了什么
12:08:31 INFO req_8fa2POST /api/ordersorder created · 201 · 184ms
按 request id 追踪请求
请求追踪用同一个 request id 串起多步
req_8fa2 · request receivedreq_8fa2 · payment checkedreq_8fa2 · order savedreq_8fa2 · response 201
查看 500 错误堆栈
500 错误用户看到简短提示，日志保留细节
页面暂时无法保存，请重试日志DB timeout · stack line 42
监控错误率与响应耗时
运行监控从日志汇总错误率和耗时
请求量12.4kP95 延迟820ms错误率8.2%告警已通知
快速练习