重写规则实战：重定向接口、改请求参数、改响应状态
理论模式清楚了，这篇用三个典型例子把重写用起来。
例一：重定向到另一个地址
把发往 hello.com 的请求转到 world.com 拿结果，类似 Map Remote 但更细粒度。创建重定向规则时填写原 URL 与新 URL，支持通配符：
原请求：
https://hello.com/foo/bar/ok?abc=123重定向规则设为：
https://world.com/new/*实际请求会变成：
https://world.com/new/foo/bar/ok?abc=123
三个注意点：
- 保留头部 Host：一般不建议开启，不同服务端对 Host 的处理逻辑不同，可能导致请求失败；
- 目录匹配：新 URL 以
/*结尾表示匹配原地址的子目录； - 排除 URL：可选项，配置后被排除的 URL 不做重定向。
另外，如果原请求的服务器地址无法响应，会直接导致请求失败（不会发起重定向请求）。
例二：正则修改请求参数
想改请求参数里 key 的值但保留其他参数。比如：
https://reqable.com?key=12345&foo=bar&hello=world固定值替换：创建一个 key 的匹配替换规则即可。
值未知时：用正则表达式匹配任意值再替换。
带分组引用：想在原值基础上加前缀 api-，用正则加 $ 分组替换实现。
一个请求可以叠加多个修改规则，在列表里统一管理：
限制：修改模式不支持改请求方法和请求路径；不要手改 Content-Length 头，它会被自动重算。
例三：整体替换响应（Mock 固定返回）
用「替换响应」行为，把响应状态、响应头、响应体整体换成预设内容。响应体支持空、文本和本地文件三种类型——本地文件方式配合 Map Local 思路，可以把大段 JSON 放在文件里维护。
替换请求同理，支持替换请求方法、路径、头和体；从调试列表右键创建时数据自动填充。
怎么验证规则生效
规则启用后，重新触发目标请求，在调试列表里查看该请求的详情——被替换或修改的内容会直接体现在请求/响应数据里。规则不生效时依次检查：规则开关是否打开、URL 匹配模式是否写对、规则在列表中的顺序是否被前面的规则抢先命中。