共计 1403 个字符，预计需要花费 4 分钟才能阅读完成。
背景痛点
在 API 开发和测试过程中，经常需要动态修改请求或响应头信息。常见的场景包括：
- 切换不同环境的鉴权 token
- 测试不同 API 版本控制（如 Accept 头）
- 模拟移动设备 UA 标识
- 调试 CORS 相关 Header
手动修改代码或重新打包应用来测试这些场景效率极低，而 Charles 提供的 Header 修改功能可以即时生效，大大提升调试效率。
工具对比
主流抓包工具对 Header 修改的支持对比：
- Postman：适合手动构造请求，但无法拦截和修改真实客户端请求
- BurpSuite：功能强大但配置复杂，适合安全测试
- Charles：界面友好，支持图形化修改，最适合开发调试场景
核心操作
1. 启用 Breakpoints 功能
- 打开 Charles，确保已开启代理（Proxy > Proxy Settings）
- 选择菜单栏的【Proxy】>【Breakpoint Settings】
- 点击【Add】添加需要拦截的请求（支持通配符 *）
2. 修改 Header 参数
当请求被拦截后：
- 在弹出的 Breakpoints 编辑窗口选择【Edit Request】
- 切换到【Headers】标签页
- 修改或添加需要的 Header 键值对
- 点击【Execute】继续请求
Conditional Breakpoints
对于需要条件触发的场景：
- 在 Breakpoint Settings 勾选【Enable Conditional Breakpoints】
- 设置匹配规则（如 URL 包含
/api/v2时触发）
代码级示例
原始请求报文
GET /api/user HTTP/1.1
Host: example.com
Authorization: Bearer old_token
Accept: application/json修改后报文
GET /api/user HTTP/1.1
Host: example.com
Authorization: Bearer new_token # 修改处
Accept: application/xml # 修改处
X-Mock-Data: true # 新增头避坑指南
签名校验处理
当遇到签名校验的 API 时：
- 先正常请求一次获取原始签名
- 在 Breakpoints 中保留原签名头不做修改
- 或使用 Charles 的 Map Local 功能返回预签名响应
常见错误解决
- 413 错误：检查是否意外修改了 Content-Length
- 400 错误：确认 Header 格式符合 RFC 规范（特别注意冒号后要有空格）
- SSL 错误：确保已安装 Charles 根证书
高阶技巧
Map Local 批量修改
- 准备包含目标 Header 的本地响应文件
- 右键请求选择【Map Local】
- 选择本地文件并启用【Preserve headers】选项
External Proxy 自动化
通过外部代理脚本实现：
- 在 Tools > External Proxy Settings 启用外部代理
- 编写脚本处理 HTTP 流（支持 Python/Ruby 等）
- 在脚本中动态注入 Header
修改效果验证 checklist
- [] 修改后的 Header 值确实生效
- [] 没有破坏必需的签名头
- [] Content-Type 与请求体匹配
- [] 测试了边界情况（空值 / 特殊字符）
- [] 验证了移动端 /Web 端不同客户端表现
通过本文介绍的方法，可以高效完成各种 Header 修改需求，建议先在不重要的测试环境练习熟悉后再应用到生产调试。Charles 的这个功能在我们最近的微服务迁移项目中节省了大量重复打包部署的时间，特别是需要测试不同版本 API 兼容性时特别有用。
正文完
