先看一张简化图：
Client
|
v
[accept/read]
|
v
[server rewrite]
|
v
[find location]
|
v
[location rewrite] -- URI changed? --> [find location again]
|
v
[access]
|
v
[content / proxy_pass / upstream]
|
v
[header filter]
|
v
[body filter]
|
v
[log]
|
v
Response在 OpenResty 里，你最常接触的是这些挂钩点：
init_by_lua* 启动装配：主进程加载配置/模块
init_worker_by_lua* 工人上岗：每个 worker 初始化
rewrite_by_lua* 改写 URI、变量、路由前置处理
access_by_lua* 鉴权、限流、ACL、风控
balancer_by_lua* 动态选上游
content_by_lua* 直接生成响应
header_filter_by_lua* 改响应头
body_filter_by_lua* 改响应体流
log_by_lua* 请求收尾日志
ssl_certificate_by_lua* 动态证书/TLS 阶段逻辑#1. rewrite 阶段：决定请求去哪
这是“粗加工工位”。常干这些事：
- 改 URI
- 解析路径参数
- 设置 Nginx 变量
- 提前决定某些路由分支
适合做“路径整形”，不适合塞太重的业务判断。
#2. access 阶段：决定能不能过
这是最像“闸机”的工位。常见职责：
- 鉴权
- 限流
- 黑白名单
- 配额
- 机器人拦截
- 租户隔离
很多 API 网关价值，基本都集中在这里。
#3. balancer 阶段：决定送到哪台上游
这是“分拣机械臂”：
- 灰度发布
- 金丝雀路由
- 按租户选集群
- 按权重、健康状态、标签选节点
如果你想做“真正动态”的上游决策，这里很关键。
#4. header_filter / body_filter：回程加工
请求打完上游回来，还能继续加工：
- 加/改响应头
- 统一错误格式
- 注入追踪 ID
- 裁剪或转换响应体
但这里有个重要认知：filter 阶段是在“响应流动中”工作，不是拿到完整结果后再慢慢处理。
#5. log：收尾，不是主战场
适合做：
- 打点
- 异步上报
- 埋点
- 请求画像汇总
不适合在这里做影响主路径正确性的关键业务。