在Burp Suite里做项目时，很多人会把项目文件和项目配置当成同一件事，结果前面明明已经导出了配置，后面换一台机器或者换一个项目时，却不知道该从哪里重新接进去。PortSwigger官方现在把这两层分得很清楚。项目文件用来保存当前项目的数据和项目级设置，配置文件则是JSON格式的设置集合，可以单独导入、导出和重复加载。也就是说，真正想复用的通常不是整个项目，而是配置本身，所以导入和复用时要先分清你拿在手里的到底是project file还是configuration file。

在Burp Suite里处理Proxy历史记录，最容易混掉的是两件事。一件事是把当前已经抓到的记录清掉，另一件事是以后别再继续堆很多。PortSwigger现在的官方文档明确说明，HTTP history主要负责展示经过Burp Proxy的浏览器流量，过滤器只影响显示，不会删除数据；而Proxy设置页则提供了“不要再把请求送进Proxy history”的控制项。也就是说，清理和限量不是同一个入口。

在Burp Suite里，宏本质上不是“录屏回放”，而是一组从Proxy历史记录里挑出来、按顺序执行的HTTP请求。PortSwigger官方文档写得很直接，宏通常用来处理登录、会话恢复和令牌更新这类需要重复走一遍的流程；而真正让宏在测试里自动生效的，不是宏本身，而是后面的Session handling rule。也就是说，先把宏录对，再把规则挂对，登录流程复用才会稳。

Burp Suite里的Comparer，本质上就是一个专门做可视化差异对比的小工具。PortSwigger官方文档写得很直接，它可以拿来比较任意两段数据，最常见的用法就是对比两条请求或两条响应，快速找出那些肉眼不容易一眼看出来的细微变化。真正用顺以后，它特别适合拿来比登录前后响应、不同参数下的请求差异，或者同一接口在不同权限下返回内容的变化。

在Burp Suite里用Decoder，看起来像是把一段编码内容丢进去再点一次解码就结束了，但实际使用里最常见的问题不是不会点，而是数据本身有多层编码、截断、压缩、混合格式，或者当前选择的解码方式根本和原始数据不匹配。PortSwigger官方现在把Decoder的定位说得很明确，它既支持手动解码，也支持自动识别并解码可识别的格式，比如URL编码；同时，Inspector也会在很多场景里自动解码选中的数据。所以真正高效的做法不是只守着一个窗口，而是先分清数据是不是“Burp能自动识别的格式”，再决定是用Decoder手动拆，还是借Inspector先看一轮。

Burp Collaborator 本质上是一套 OAST 服务，也就是用“目标站点是否主动回连外部域名”来验证那些页面上看不出明显回显、报错或延时差异的问题。PortSwigger 官方文档写得很清楚，Burp 会先把一个 Collaborator payload 发到目标应用里，再由 Burp 轮询 Collaborator 服务器，看有没有 DNS 或 HTTP 这类交互发生。所以它的使用重点，不是先盯响应包，而是先把 payload 放到合适的位置，再去看有没有回连。

在授权测试场景里，BurpSuite做手工验证时，常见痛点不是抓不到包，而是请求改完要回放很多次，列表一多就容易漏看关键差异。更顺的做法是先用Repeater把请求改到可复现，再用Repeater的分组发送把一组请求批量回放，等基线响应稳定后，再把同一条请求送进Intruder做参数变异，把异常响应筛出来，最后回到Repeater复核复现。

BurpSuite里改了请求但服务器侧看起来没变化，通常不是编辑框没保存，而是你改的那一条并没有真正被转发出去，或者被拦截规则放行了没有停下来，又或者被自动规则二次改写覆盖。按下面顺序把流量是否经过、拦截总开关、拦截规则组合顺序、自动改写规则执行顺序逐个核对，问题一般能在十分钟内收敛到具体开关与具体规则上。

BurpSuite证书通常被安装到系统或浏览器的受信任根证书里，用于让浏览器在走代理时不报证书错误。卸载时如果只删了证书但没关代理，或者只关了代理但浏览器里还残留证书与缓存，就容易出现打不开网站、一直提示不安全、连不上代理这类现象。下面按先卸载证书，再恢复访问的顺序，把常见平台的操作路径写清楚。

BurpSuite抓HTTPS流量时用的是本机生成的一套CA证书，你一旦更换或重生成CA，浏览器和设备端原先信任的证书链就会失效，表现为页面报证书错误或历史里只剩下CONNECT看不到内容。处理思路很固定，先在Burp里重生成或迁移CA，再把新CA安装到你实际使用的信任库里，最后把旧CA从各端清理掉并做一次验证闭环。