企业官网建设流程全解析

做安全这几年，被问到频率最高的一个实操问题就是：XSS 到底上哪练？很多人的第一反应是找几个线上站点试试手，这个念头本身就该掐掉——未经授权对任何非自有资产做注入测试，性质和结果都不在你的控制范围内。更靠谱的做法是自己搭一个可控的 XSS 平台，把反射型、存储型、DOM 型这三条链路完整跑一遍，既能验证自己的检测思路，也能顺手把防御代码写进去做对照。这篇就来聊聊我在搭这类演练平台时踩过的路、做过的取舍，以及那些看起来不起眼但会让整个平台跑不起来的小细节。不管你是刚入门想找个练手环境，还是已经做过几轮安全评审想沉淀一套可复用的自检工具，下面的内容应该都能直接拿去用。

1. 先想清楚这个XSS平台是给谁用的

很多人一上来就打开编辑器写代码，结果搭到一半发现方向不对，推倒重来。搭之前花二十分钟把用途定下来，能省掉后面大把返工时间。就我接触过的情况看，XSS 平台大致落在三个用途上，每个用途对架构的要求完全不一样。

1.1 三种用途决定了三套完全不同的架构

第一种是教学演练。面向的是刚接触 Web 安全的人，重点在于现象要直观、步骤要清晰，点一下按钮就能看到弹窗，不需要理解背后的数据流。这种平台对性能毫无要求，单机单进程，甚至一个 HTML 文件就能凑合，关键是每个实验单元独立、结果明确。

第二种是自动化检测验证。这种用途下，平台本身是一个被测目标，你要拿自己的扫描器去跑，看它能不能准确识别出哪些接口存在输出未编码的问题。这时候平台的接口数量要够多、变体要够全，要覆盖参数回显、富文本存储、前端动态渲染等多种形态，同时还得能自动重置数据，不然跑两轮数据就脏了。

第三种是防御方案对照。这种最有意思，同一套业务逻辑做两份实现，一份是存在问题的版本，一份是修好的版本，两边用同样的输入跑一遍，直观看到差异。这种平台的价值在于，它能把"输出编码""内容安全策略""Cookie 保护属性"这几个防御手段的实际效果摆出来，比看十篇文档都管用。

我在实际搭的时候是把三种揉在一起：底层共用一套数据模型，通过路由参数区分"有问题的实验单元"和"已修复的对照单元"，这样一套环境三件事都能干。代价是目录结构会稍微复杂一点，但比起维护三套独立环境要划算得多。

1.2 授权边界必须写在代码里，而不是记在脑子里

这一点我必须单独拎出来讲。演练平台最大的风险不是技术问题，而是有人拿着它去对着真实站点跑。所以平台在设计阶段就要把边界做进代码：所有测试入口只能访问本机回环地址或平台内部网络，检测模块的目标地址需要显式配置白名单，不在白名单里的域名直接拒绝执行。

具体实现上，可以在发起任何请求之前加一层校验，只允许解析结果落在私有网段的地址通过。这样做除了防止误操作，还能顺带挡掉一类很常见的坑——检测模块被配置成跟随跳转，结果一路跳到了外网，测试行为直接失控。这层校验写起来不到三十行代码，但能挡掉绝大多数意外。

提示：平台部署完成后，第一时间确认它的访问范围。默认只监听回环地址，需要局域网内其他人访问时再显式放开，并配合访问口令。

1.3 平台要预留"重置"这个动作

这个经验是我被坑过一次才总结出来的。存储型实验单元的核心特征就是数据会落库，跑几轮测试之后，留言板里塞满了各种测试向量，页面加载越来越慢，有时候还会因为数据里带了特殊字符导致页面结构错乱，看起来像是平台坏了，其实是脏数据。

所以从第一天起，每个存储型实验单元都要配一个数据重置入口，能在几秒内把表清空并重新灌入初始样例数据。我现在的做法是给每个实验单元单独建表，重置时直接执行建表语句加初始数据插入，比逐条删除要快，也更干净。更进一步的做法是把整个数据库文件做成可替换的，重置就是换一个预置好的文件副本，速度更快。

2. 底座选型：为什么最后落在容器编排加轻量后端

选型这块我前后换过三次方案，从最早的本地脚本直连数据库，到后来的虚拟机快照，最后稳定在容器编排。中间的过程值得说说，因为这直接决定了后面维护成本的高低。

2.1 单体脚本和容器编排的真实差别在哪

一开始我是用最朴素的方式：本地装个运行时，写几个路由脚本，数据库用文件型的，启动就是跑一个命令。这种方式上手极快，半小时就能看到第一个实验页面。但问题在两处：一是环境依赖会漂移，换了台机器可能因为运行时版本差异跑不起来；二是数据库文件散落在项目目录里，重置和备份都靠手动复制，容易出错。

容器编排解决的正是这两个问题。镜像把运行时版本锁定，编排文件把服务间的依赖关系和服务启动顺序写死，数据目录通过挂载卷暴露到宿主机上，重置和备份就是操作宿主机上的一个目录。代价是需要多理解一层网络模型和卷挂载规则，但一次性投入换来的是长期省心。

我整理了一下两种方式的实际差异，你可以对照自己的场景选：

2.2 一份能直接用的编排骨架

下面这份编排文件是我目前用的简化版，去掉了监控和日志采集的部分，保留了核心结构和自检逻辑。数据存储用轻量数据库，避免为了练手环境再拖一个重量级服务进来：

services: lab-web: build: ./app container_name: xss-lab-web ports: - "127.0.0.1:8080:8080" environment: - DB_FILE=/data/lab.db - RESET_TOKEN=change-me-before-deploy volumes: - ./data:/data - ./app:/app restart: unless-stopped healthcheck: test: ["CMD", "curl", "-f", "http://localhost:8080/healthz"] interval: 20s timeout: 5s retries: 3 networks: - labnet networks: labnet: driver: bridge

几个细节值得说明。端口绑定用了127.0.0.1前缀，这是前面说的边界控制落到配置层；DB_FILE指向挂载卷里的路径，容器重建数据也不会丢；RESET_TOKEN是重置接口的调用凭证，避免被随手点掉；健康检查让编排工具能感知服务状态，配合restart策略处理偶发的启动失败。

2.3 目录结构怎么切分才不会越写越乱

项目文件一多就容易变成一锅粥。我现在的切法是按"关注点"分四层，每层职责单一：

xss-lab/ ├── app/ │ ├── main.py # 应用入口与路由注册 │ ├── labs/ │ │ ├── reflected.py # 反射型实验单元 │ │ ├── stored.py # 存储型实验单元 │ │ ├── dom.py # DOM 型实验单元 │ │ └── fixed.py # 修复对照单元 │ ├── models/ │ │ └── schema.py # 建表与初始数据 │ ├── scanner/ │ │ ├── crawler.py # 链接与表单发现 │ │ ├── injector.py # 测试向量注入 │ │ └── judge.py # 结果判定 │ └── templates/ # 页面模板 ├── data/ # 数据库挂载目录 └── compose.yaml

分层的好处是加新实验单元时只需要在labs目录下新增一个文件并注册路由，不用动其他任何代码。扫描器部分独立成包，意味着它也可以脱离平台单独跑，对着别的目标做检测——当然是在授权范围内。

3. 反射型与存储型实验单元的落地实现

这两个类型放在一起讲，因为它们共享同一套数据链路，区别只在于数据是即时回显还是落库后再展示。理解了这一点，实现上就只是流程长短的差异。

3.1 反射型实验单元：一个参数怎么变成执行点

反射型的本质是参数值未经处理就直接进入了响应内容。最小的实现就是一个搜索接口，把查询词原样拼回页面。这里有一个新手最容易踩的坑：如果用模板引擎的默认渲染方式，它会自动做转义，你的测试向量根本不会生效，然后你会以为是环境没搭对，反复折腾半天。

以常见的模板引擎为例，默认写法会把尖括号和引号转成实体字符，页面显示出来的是字面文本而不是可执行内容。要在实验单元里复现问题，必须显式关闭转义。下面这段是实验单元的写法：

from flask import Flask, request app = Flask(__name__) @app.route("/lab/reflected") def lab_reflected(): q = request.args.get("q", "") # 实验单元：刻意关闭转义，用于观察输出未编码的实际表现 return f"<div class='result'>你搜索的是：{q}</div>" @app.route("/fix/reflected") def fix_reflected(): q = request.args.get("q", "") # 对照单元：默认转义，输入被当作纯文本处理 from markupsafe import escape return f"<div class='result'>你搜索的是：{escape(q)}</div>"

两个路由放在同一个应用里，页面提供互相跳转的链接，输入同样的内容，一边是页面结构被改变，一边是原样显示。对比效果一眼就能看明白，比口头解释"输出编码"这个概念有效得多。

测试向量不需要多复杂，一个基础的标签结构就够验证。真正重要的是理解为什么它会生效：浏览器拿到响应后，按 HTML 解析规则构建文档树，你的输入落在了标签上下文里，于是被当成标记语言的一部分解析并执行。理解了这条链路，你才知道防御该在哪一环下手。

3.2 存储型实验单元：数据落库之后才是麻烦的开始

存储型和反射型的唯一区别是数据多走了一段持久化路径，但正是这段路径带来了一堆需要处理的问题。

第一个问题是字段长度的限制。测试向量的长度差异很大，如果数据库字段定义得太短，插入会被截断，现象看起来就是"有时候生效有时候不生效"，极难排查。我的做法是正文类字段统一用变长文本类型，不做长度约束，真要在应用层限制就单独写校验逻辑。

第二个问题是初始数据和测试数据的混杂。平台刚上线时留言板里应该有几条正常的示例留言，让页面看起来像个真实场景；但测试跑完之后这些数据就没用了。所以重置逻辑要能把表恢复到初始状态，而不是清空。下面这个建表加初始化的写法很实用：

INIT_SQL = """ CREATE TABLE IF NOT EXISTS guestbook ( id INTEGER PRIMARY KEY AUTOINCREMENT, nickname TEXT NOT NULL, content TEXT NOT NULL, created_at TEXT NOT NULL ); """ SEED = [ ("小明", "这个板子看着挺清爽的。"), ("阿May", "第一次来，留个脚印。"), ] def reset_table(conn): conn.execute("DROP TABLE IF EXISTS guestbook") conn.executescript(INIT_SQL) for name, text in SEED: conn.execute( "INSERT INTO guestbook(nickname, content, created_at) VALUES (?, ?, datetime('now'))", (name, text), ) conn.commit()

注意存的时候用了参数化写法，这一步很关键。存入时用参数化避免存储环节本身出问题，但取出渲染时不做编码——这样问题就精确地定位在"输出环节未编码"这一个点上。如果存取两端都出问题，你会分不清到底是哪一环导致的，排查成本翻倍。

3.3 三种类型的对照表

把三个类型的关键差异列在一起，搭平台的时候对着看，能少走很多弯路：

这张表里最有价值的一列是"复现难点"。很多人在搭存储型的时候卡住，排查半天网络请求，其实问题出在数据库字段长度上，请求本身完全正常。知道难点在哪，排查就能直奔主题。

4. DOM型实验页面：不经过服务端的那条路径

DOM 型是最容易被误解的一类。它的特征非常明确：完整的测试输入从头到尾没有进入服务端响应，服务端日志里看不到任何异常，但页面在浏览器里确实执行了不该执行的内容。如果你习惯了看请求响应来判断问题，这一类会让你怀疑人生。

4.1 常见的注入点其实有固定套路

虽然具体写法千变万化，但能导致 DOM 型问题的前端接口就那么几个，我整理了一份清单，搭实验单元和做代码审计时都能用：

这份清单的价值在于，做前端代码审计的时候可以按名字全局搜索，命中一处就人工确认一处，效率比漫无目的地读代码高得多。

4.2 一个完整的DOM型实验页面

下面的页面刻意做了一个经典场景：从地址栏取参数，直接塞进元素内容。整个流程没有一次服务端请求，所有的信息都在 URL 的片段部分里：

<!DOCTYPE html> <html lang="zh-CN"> <head> <meta charset="utf-8"> <title>DOM 型实验单元</title> </head> <body> <h3>欢迎页</h3> <div id="greeting"></div> <p>提示：试着改一下地址栏里 name 参数的值，观察页面变化。</p> <script> // 从片段标识中解析参数，这段完全不经过服务端 function getParam(key) { const raw = window.location.hash.slice(1); const params = new URLSearchParams(raw); return params.get(key) || ""; } const user = getParam("name"); // 实验单元：直接写入元素内容 document.getElementById("greeting").innerHTML = "你好，" + user; </script> </body> </html>

为什么用 URL 的片段部分而不是查询串？因为片段内容不会随请求发送到服务端，这样能更纯粹地体现"全程不经过服务端"这个特征。你打开浏览器的网络面板，会发现根本没有产生请求记录，但页面确实发生了变化。

对照单元只需要把赋值方式换掉，用纯文本写入的方式替代，效果立竿见影：

// 对照单元：按纯文本处理，不解析任何标记 document.getElementById("greeting").textContent = "你好，" + user;

4.3 为什么静态扫描工具常常漏掉这一类

理解了 DOM 型的执行时机，就能明白为什么很多静态检测手段对它束手无策。传统检测的思路是"发出请求，在响应里找注入痕迹"——而 DOM 型的问题根本不体现在响应内容里，服务端返回的永远是那份原封不动的 HTML 模板，变化发生在浏览器执行脚本之后。

要检测这一类，必须有能执行前端脚本的环境。常见做法是用无头浏览器把页面加载起来，在关键接口上打桩，记录下哪些外部数据流入了这些接口。这个思路实现起来比传统扫描复杂不少，但对单页应用越来越多的现状来说，是绕不过去的一环。我在平台里给 DOM 型实验单元单独做了一个记录页面，把浏览器上报的执行事件汇总展示，这样即使不看浏览器控制台也能确认触发情况。

5. 检测与验证模块：让平台自己跑起来

平台搭好之后只能手动点，价值就打了一半折扣。让平台具备自动跑检测的能力，才是它区别于普通演示页面的地方。这一块我踩的坑最多，值得展开讲。

5.1 测试向量的组织方式决定了维护成本

早期我是把所有向量写在一个列表里，跑的时候全量遍历。结果是效率极低，而且新增一个向量就要改代码。后来改成分类分组的结构，每个分组带一个描述字段，方便对照结果：

PAYLOADS = { "basic_markup": { "desc": "基础标记注入，用于验证标签上下文", "items": [ "<b>bold</b>", "<img src=x onerror=alert(1)>", ], }, "attribute_break": { "desc": "属性上下文闭合，验证引号处理", "items": [ "\" onmouseover=\"alert(1)", "' autofocus onfocus='alert(1)", ], }, }

分组的实际意义在于，不同的向量针对的是不同的输出上下文。往 HTML 标签之间注入和往属性值里注入，需要的写法完全不同，用错分组只会得到"没效果"的结论，然后误判成服务端做了防护。所以每次判定为"无问题"之前，先确认你的向量和上下文是匹配的。

5.2 判定逻辑不该靠字符串匹配

这是我踩过最深的一个坑。一开始我的判定逻辑是：如果响应内容里包含alert(1)就判定为存在问题。跑起来发现误报率高得离谱，因为页面上的提示文案、说明文字、示例内容里到处都可能出现这个字符串。

正确的判定思路是比对结构变化，而不是找字符串。具体做法是分三步：先用一组不含特殊字符的安全输入请求一次，把响应内容作为基线；再用测试向量请求一次，把两次的响应做结构化对比，重点看文档节点数量、标签嵌套层级这些指标有没有变化；最后在有条件的情况下用无头浏览器实际加载渲染，观察是否有脚本执行事件上报。三步结合起来，误报能压到很低。

def judge(baseline_html, test_html): from bs4 import BeautifulSoup base = BeautifulSoup(baseline_html, "html.parser") test = BeautifulSoup(test_html, "html.parser") base_tags = len(base.find_all()) test_tags = len(test.find_all()) # 标签数量出现非预期增长，说明输入被当作标记解析了 if test_tags > base_tags: return True, f"节点数量由 {base_tags} 变为 {test_tags}" return False, "结构未发生变化"

这个判定方式的另一个好处是它对各种向量都通用——不管具体写了什么，只要它导致了文档结构变化，就能被识别出来，不需要为每个向量单独写规则。

5.3 扫描范围和节流必须做成可配置

自动跑起来之后很容易失控：链接爬取没有深度限制，导致跑进了递归循环；请求发得太快，把目标服务打满。这两个问题我都遇到过，后来把参数全部提到配置层：

这些参数看似琐碎，但每一项都是从实际问题里总结出来的。特别要注意的是去重逻辑，同一个链接不同参数顺序会被当成两个不同目标，导致重复请求，处理办法是在入队前把查询参数排序后作为唯一键。

6. 搭建过程中真实踩过的坑

前面讲了架构和实现，这一节专门说那些不会写进文档、但会让平台跑不起来的问题。这些都是我自己遇到并解决的，按发生的概率从高到低排。

6.1 字符编码问题几乎必然出现

表现很典型：测试向量里带了非 ASCII 字符，提交之后页面显示成乱码，或者更隐蔽的情况——参数在传输过程中被某种编码转换了，最终落库的内容和提交的内容不一致，导致你以为是过滤逻辑起了作用，其实是编码环节把输入改掉了。

排查方法很直接：在请求处理的最开头打印原始输入，在数据落库前再打印一次，在渲染前再打印一次，三次对比就能定位转换发生在哪一环。根因通常是配置层的问题——数据库连接没有指定字符集、响应头里的编码声明和实际内容不符、或者中间层做了默认转换。

# 数据库连接显式指定字符集 conn = sqlite3.connect(DB_FILE) conn.execute("PRAGMA encoding = 'UTF-8'") # 响应头显式声明编码，避免浏览器猜测 @app.after_request def set_charset(resp): if resp.mimetype == "text/html": resp.headers["Content-Type"] = "text/html; charset=utf-8" return resp

6.2 浏览器端的防护会干扰实验观察

这个坑很隐蔽。有时候实验单元明明写对了，但浏览器就是没有按预期执行。排查半天代码，最后发现是浏览器自身的防护机制在起作用，或者是之前设置的内容安全策略还在生效，把内联脚本拦住了。

处理办法有两个方向。一是给实验单元和对照单元分配不同的路径前缀，在路径前缀层面对应不同的响应头策略，避免相互干扰。二是排查阶段先用无痕窗口打开，排除缓存和扩展的影响，确认是环境问题还是代码问题。

另外要注意同源策略的影响。如果你的实验页面通过 iframe 嵌入，而父子页面不同源，部分操作会被限制，现象就是"代码没问题但就是不动"。这种情况要么让嵌入页面同源，要么改用新窗口打开，别在跨源嵌入上浪费时间。

6.3 容器内的时钟和权限经常出幺蛾子

容器化带来的新问题。数据落库时用了默认的时间函数，容器默认是协调世界时，导致显示时间和实际时间差几个小时，看日志的时候很容易误判。解决办法是在编排文件里显式指定时区：

environment: - TZ=Asia/Shanghai volumes: - /etc/localtime:/etc/localtime:ro

权限问题是另一个。挂载卷的属主和容器内运行用户的标识不一致时，写入会失败，报错信息往往很含糊。最简单的做法是启动时用入口脚本调整挂载目录的属主，或者干脆在构建镜像时就固定好用户标识，别让它在运行期变化。

注意：挂载目录的权限问题在不同操作系统上的表现差异很大，如果你在开发机上是正常的，部署到别的机器上出问题，优先怀疑这一项。

6.4 服务启动顺序导致的偶发失败

应用启动时连接数据库，如果数据库容器还没就绪，连接会失败。虽然编排工具支持依赖声明，但依赖声明只保证启动顺序，不保证服务就绪。真正的解决办法是在应用侧加连接重试，启动时循环尝试直到成功：

import time def wait_for_db(connect_fn, retries=10, delay=2): for i in range(retries): try: return connect_fn() except Exception as exc: print(f"第 {i + 1} 次连接失败：{exc}") time.sleep(delay) raise RuntimeError("数据库在预期时间内未就绪")

配合前面编排文件里的健康检查，这套组合基本能消除启动期的偶发失败。这类问题的特点是不定期出现，一旦出现很难复现，所以要在设计阶段就处理掉，别等它上线后再抓。

6.5 文件上传类实验单元的特殊处理

顺带说一下这类场景。平台里如果包含文件上传实验单元，要特别注意一件事：上传的静态文件怎么被访问。如果上传目录和主站同源，并且浏览器按内容类型自动判断，那么某些格式的文件被直接访问时就可能被当作页面渲染，从而形成执行点。

正确的处理方式有两层。第一层是上传响应里带上内容处置头，强制按附件处理：

@app.route("/lab/upload", methods=["POST"]) def lab_upload(): file = request.files["file"] # 强制下载语义，禁止浏览器按页面渲染 resp = make_response("上传成功") resp.headers["X-Content-Type-Options"] = "nosniff" return resp

第二层是把上传的文件放到独立域名或独立端口下访问，与主站隔离。这样即使内容被渲染，也拿不到主站的任何信息。这两层组合起来，才算把这类场景处理干净。

7. 防御侧闭环：把修复代码也做成实验单元

平台的最终价值不在于复现问题，而在于验证修复是否彻底。我建议每搭一个有问题的实验单元，就同步搭一个修复版本，用同一套输入跑，对照看效果。

7.1 输出编码是覆盖面最广的一层防护

输出编码的核心思路是：在数据即将进入页面时，根据它所在的上下文做对应的转义。落在 HTML 文本里就转义尖括号和与号，落在属性值里还要额外处理引号，落在脚本块里则要用完全不同的编码方式。

这里有个细节很多人搞错：转义必须发生在输出环节，而不是输入环节。存入数据库时就做转义，会导致数据在非页面场景下使用出错，而且一旦某处忘记解码就会重复转义，页面上显示出一堆实体字符。正确做法是原样存储，渲染时再按上下文处理。

from markupsafe import escape # 文本上下文 safe_text = escape(user_input) # 属性值上下文，额外处理引号 safe_attr = escape(user_input, quote=True)

7.2 内容安全策略是兜底，不是主力

内容安全策略的价值在于，即使某一处编码漏了，它也能拦住大部分执行。但它绝不能当成唯一的防线，因为它对同源脚本的执行是放行的，而很多注入点恰恰就在同源页面里。

配置的时候从最严格的策略开始，然后根据实际报错逐步放开，比反过来要安全得多。下面是一个可用的起点，禁止所有内联脚本和外部脚本源，只允许同源：

@app.after_request def apply_csp(resp): resp.headers["Content-Security-Policy"] = ( "default-src 'self'; " "script-src 'self'; " "object-src 'none'; " "base-uri 'self'; " "frame-ancestors 'self'" ) return resp

要注意frame-ancestors这一项，它防的是页面被其他站点嵌入后用于诱导操作，属于附加收益。上线前必须确认策略不会影响正常的业务脚本，测试环境跑一轮再放开。

7.3 会话凭证的保护属性要记得加上

即使页面被注入了内容，如果会话凭证带了保护属性，脚本也读不到它。这是个成本极低、收益明确的措施：

resp.set_cookie( "session_id", value=token, httponly=True, # 脚本不可读 secure=True, # 仅加密连接传输 samesite="Lax", # 限制跨站携带 )

三个属性里，httponly是底线，必须加。secure要求在加密连接下部署，本地演练环境可以按需调整。samesite的取值要根据业务场景选，太严格会导致正常的跨站跳转登录失效。

7.4 一个容易忽略的场景：动态渲染类功能

现在很多系统都带表单设计器或者页面搭建功能，用户通过界面配置就能生成页面。这类功能有个共同特征：配置内容会被动态渲染成 DOM。如果渲染时用了前面第 4 节提到的那几个接口，且配置内容没有经过校验，就形成了一个很隐蔽的入口。

处理这类场景要多做一步：在保存配置时，对所有会进入动态渲染的字段做一次结构校验，限定允许的标签和属性范围。这一步的成本是引入一个解析库，收益是把风险挡在存储之前，比在渲染环节做转义要可靠——因为渲染路径可能有多条，漏掉任何一条都会出问题，而入库路径通常只有一条。

8. 我在实际维护中的几点体会

平台搭完只是开始，长期维护下来有些经验值得分享。

第一是每次改完代码都要跑一遍完整回归。这类平台的脆弱点在于，一个实验单元的改动可能影响另一个的判定结果。我现在的做法是每次提交前用脚本把所有实验单元跑一遍，确认每个的现象和对照单元都符合预期。

第二是把平台的使用记录留存下来。不是为了审计，而是排查问题时能回看当时的状态。记录内容包括访问时间、目标路由、使用的测试向量编号、判定结果。有了这份记录，发现异常结果时能快速判断是新问题还是已知问题。

第三是定期回看平台的网络暴露面。部署时间长了容易忘记当初的配置，端口是否还只监听回环、白名单是否还是当初那份、口令是不是还是默认值，这些都需要定期确认。我一般会每隔一段时间重新过一遍编排文件，把不再需要的端口映射和白名单条目清掉。

最后一个小技巧：给每个实验单元写一句简短的说明，直接展示在页面上，写清楚这个单元演示的是什么链路、观察重点是什么。看起来是小事，但隔几个月再回来的时候，你会庆幸当初写了这句话。