残留目录清理指南：从构建到部署的工程化防漏实践

前阵子网上有个说法传得挺有意思：某游戏项目更新后，老版本内容还留在线上，疑似工程师偷懒，文件夹没删。这个说法具体细节无从考证，但类似的事情在开发圈并不少见：接口发布后依然返回旧逻辑，前端页面改了刷新还是老样式，后台配置改了却不生效，最后排查半天，发现都是“旧文件夹”在作怪。本文不讨论八卦，只认真拆解“文件夹没删”背后的工程问题——残留目录如何影响构建、部署和线上运行，以及如何用一套可复用的脚本和流程，把清理这件事从“靠记忆”变成“靠机制”。

1. 从“文件夹没删”说起：一次事故背后的工程启示

1.1 还原“段子”背后的工程场景

游戏、Web 应用或后端服务迭代时，下线一个旧功能通常不只是删几行代码那么简单。功能下线往往涉及旧资源、旧配置、旧路由、旧接口、旧静态文件等一系列内容的清理。而在真实项目里，删除永远比新增麻烦：新增代码只要写对即可，删除却需要确认“没有其他地方还在引用”。

网上流传的“工程师偷懒，文件夹没删”，翻译成工程语言就是：发布过程中没有执行可重复、可审计的清理动作。旧文件夹继续保留在发布目录、版本目录或 Classpath 中，新代码和旧代码同时存在，最终线上行为变得不可控。更麻烦的是，这种问题往往不会立刻报错，因为文件名相同、目录层级相同，服务可以正常启动，只是用户访问到的可能是旧逻辑。

1.2 残留目录到底会影响什么

很多人以为残留目录只是多占一点磁盘空间，其实危害远不止于此。我们可以按开发、构建、部署、运行四个阶段来看。

开发阶段，IDE 和构建工具会把编译产物写到 target、dist、build 等目录。如果这些目录没有清理，删除过的类文件或资源文件可能仍然存在，下次增量编译时会被重新打进去，导致本地行为和代码不一致。

构建阶段，增量构建默认会“保留旧产物”。比如用 Maven 执行 mvn package 而没有先执行 mvn clean，target/classes 里旧版本的 .class 文件不会被自动删除。假设你从代码里删除了一个类，但旧 .class 还在，最终生成的 jar 包里就仍然包含这个类。

部署阶段，如果服务器上存在上一版本的完整目录，新旧目录同时存在，很容易出现 Classpath、静态资源路径、配置文件加载顺序混乱。尤其是使用 Tomcat、nginx 这类中间件时，目录优先级一变，访问到的可能就是旧内容。

运行阶段，旧配置残留可能导致配置中心的新配置不生效，旧静态资源被浏览器或 CDN 缓存命中，旧接口仍然可以访问。更严重的是，如果旧版本存在安全漏洞，但代码已经修复，残留的旧文件会让补丁“看似上线，实则未生效”。

1.3 为什么“靠记得删除”不靠谱

这个问题的根因不是某个工程师不够细心，而是删除操作本身没有被纳入工程流程。人的记忆在发布窗口紧张、多人协作、频繁切换分支时非常不可靠。删除动作如果没有日志、没有审批、没有回滚方案，事后也无法追溯。

另外，不同操作系统的删除命令和行为不一致，手动删除容易漏掉深层子目录。真正可靠的清理动作应该满足三个条件：幂等，重复执行结果一致；可预览，先列清单再执行；可自动化，能够嵌入构建和发布流程。这其实就是 CI/CD 里“干净构建”的基本思想。

2. 复现一次“旧文件夹覆盖新代码”的小实验

2.1 实验设计

为了更直观地理解问题，我们先做一个最小复现实验。假设有一个发布目录 publish，里面已经放入了新版本的 static/app.js。另一个 legacy/static/app.js 是旧版本遗留目录。如果发布脚本写得不严谨，把 legacy/static 整个目录复制到 publish/static，旧文件就会覆盖新文件，但整个流程不会报错。

实验会用到 pathlib 和 shutil，都是 Python 标准库，在常见的 Python 3 环境中可以直接运行。核心目的是展示文件目录覆盖的“静默性”：一切都很正常，但线上逻辑已经变了。

2.2 使用 Python 复现目录覆盖

创建一个 Python 脚本，比如 reproduce_overwrite.py，代码如下：

python复制from pathlib import Path
import shutil

# 模拟发布目录中的新版本文件
publish_static = Path("publish/static")
publish_static.mkdir(parents=True, exist_ok=True)
(publish_static / "app.js").write_text(
    "console.log('new version');\n",
    encoding="utf-8"
)

# 模拟旧版本遗留目录
legacy_static = Path("legacy/static")
legacy_static.mkdir(parents=True, exist_ok=True)
(legacy_static / "app.js").write_text(
    "console.log('old version');\n",
    encoding="utf-8"
)

# 错误的发布动作：把旧 static 目录整体覆盖到发布目录
shutil.copytree(legacy_static, publish_static, dirs_exist_ok=True)

# 最终发布目录中的 app.js 是什么？
print((publish_static / "app.js").read_text(encoding="utf-8"))

运行 python reproduce_overwrite.py，输出结果：

code复制console.log('old version');

shutil.copytree 的 dirs_exist_ok=True 参数从 Python 3.8 开始可用，如果本机 Python 版本较旧，需要调整写法。这个实验的核心结论是：目录覆盖是“无差别”的，它不会因为目标文件更新就跳过旧文件，文件名相同、目录层级相同，旧内容就直接覆盖过去了。

2.3 用 Maven 构建解释旧 Class 残留

静态资源覆盖的问题很直观，Java 后端里更隐蔽的是 .class 文件残留。假设有一个 Spring Boot 项目，类 OldService.java 在新版本中已经被删除，但 target/classes/com/example/OldService.class 还躺在上一次构建的产物里。

如果直接执行 mvn package，Maven 会基于 target/classes 目录打 jar 包，目录里多出来的 OldService.class 并不会被自动识别为“不该存在”。最终 jar 包里仍然包含这个类，线上接口依然可以通过访问路径找到它。这就是很多“旧接口一直存在”问题的根源。

正确的做法是在打包前先执行：

bash复制mvn clean package

clean 会把 target 目录删除，然后重新编译、重新打包。Gradle 项目也类似，发布前建议执行：

bash复制gradle clean build

2.4 实验结论

通过上面的小实验，我们可以总结出“文件夹没删”可能带来的几类隐藏危害。

第一，旧接口或旧路由仍然可访问。因为旧 .class 文件或旧代码目录还在 Classpath 中。第二，静态资源版本错乱。文件名相同的新旧文件被目录覆盖逻辑弄混，用户拿到旧 JS、旧 CSS。第三，配置不生效。本地残留的 application.yml、config.properties 优先级高于远端配置中心，改了中心配置也没用。第四，安全补丁失效。旧版本包含已知漏洞，即使新代码已经修复，旧文件残留依然暴露风险。第五，构建包体积异常变大。删除文件后未清理产物，jar、镜像或压缩包里包含大量无用历史文件。

这些问题都有同一个特征：不在第一时间报错，只在特定功能被访问时暴露，排查成本很高。

3. 环境准备与清理脚本设计

3.1 本文实验环境

后面的脚本和示例不依赖特定操作系统，Windows、Linux、macOS 都可以运行。主要环境如下：

• Python 3.8 及以上版本，用于执行目录扫描与清理脚本。
• 终端工具，用于运行命令。
• 一个模拟项目目录，建议包含 target、dist、node_modules、__pycache__ 等常见目录。

示例目录结构可以是：

code复制demo-project/
├── src/
├── target/
├── dist/
├── node_modules/
└── __pycache__/

版本不需要完全一致，关键是理解清理脚本的设计思路：只扫描白名单目录，默认不删除，先展示清单再确认。

3.2 清理脚本设计原则

清理脚本最重要的不是删除功能，而是安全。一个不安全的清理脚本可能比残留目录本身更可怕。设计时应遵循几个原则。

幂等原则：脚本重复执行多次，结果一致，不会因为第一次漏删导致第二次误删。默认安全原则：脚本只打印待清理列表，不实际删除，必须显式传入删除参数才执行删除。白名单原则：只处理约定的目录名，比如 target、dist、node_modules、__pycache__，绝不扫描整块磁盘。输出可读原则：让操作者清楚知道哪些目录会被删，删除前还要二次确认。

为什么要默认不删除？因为清理目录往往是不可逆操作。如果目录里恰好有未提交的构建脚本、手工放进去的配置，直接删除会造成损失。先看后删，是工程师对自己和团队负责的做法。

3.3 编写安全的残留目录清理脚本

下面给出一个可直接使用的清理脚本 clean_workspace.py。它会递归扫描指定目录，找出常见的构建产物目录和依赖目录，默认只打印，不删除。只有加上 --delete 参数并且输入 yes 确认后，才会真正执行删除。

python复制#!/usr/bin/env python3
"""清理常见构建目录与依赖目录的辅助脚本。

用法示例：
    python clean_workspace.py /path/to/project
    python clean_workspace.py /path/to/project --delete
"""
import argparse
import shutil
from pathlib import Path

# 只清理这些命名约定的目录，避免误删其他内容
TARGET_DIRS = {
    "node_modules",
    "dist",
    "build",
    "target",
    "out",
    ".venv",
    "venv",
    "__pycache__",
    ".pytest_cache",
    ".gradle",
    ".idea",
    ".next",
    ".cache",
    "logs",
}


def scan(path: Path, max_depth: int, depth: int, results: list):
    """递归扫描目录，把匹配的目录加入 results。"""
    if depth > max_depth:
        return
    try:
        children = list(path.iterdir())
    except PermissionError:
        # 无权限访问的目录直接跳过
        return
    for child in children:
        # 不跟踪符号链接，避免误删链接指向的真实目录
        if child.is_symlink():
            continue
        if child.is_dir():
            if child.name in TARGET_DIRS:
                results.append(child)
            else:
                scan(child, max_depth, depth + 1, results)


def main():
    parser = argparse.ArgumentParser(description="扫描并清理常见残留目录")
    parser.add_argument("root", nargs="?", default=".", help="待扫描的根目录")
    parser.add_argument("--delete", action="store_true", help="实际删除，不加则只打印")
    parser.add_argument("--max-depth", type=int, default=8, help="最大递归深度")
    args = parser.parse_args()

    root = Path(args.root).resolve()
    if not root.exists():
        print(f"[错误] 目录不存在: {root}")
        return

    results = []
    scan(root, args.max_depth, 0, results)

    if not results:
        print("没有发现需要清理的目录。")
        return

    print(f"共发现 {len(results)} 个待清理目录：")
    for item in results:
        print(item)

    if not args.delete:
        print("\n当前为预览模式，加入 --delete 参数后才会真正删除。")
        return

    confirm = input("\n确认删除以上目录？输入 yes 继续：")
    if confirm.strip().lower() != "yes":
        print("已取消，未删除任何内容。")
        return

    for item in results:
        print(f"删除: {item}")
        shutil.rmtree(item)
    print("清理完成。")


if __name__ == "__main__":
    main()

脚本中有几个细节值得说明。child.is_symlink() 的判断很重要，如果不做判断，脚本可能顺着软链接进入目录外部甚至系统目录，删除逻辑会变得不可控。PermissionError 的捕获保证脚本在部分目录无权限时不会中断。默认的 --delete 是关闭的，配合二次确认，可以避免手滑。

在演示项目上先运行预览模式：

bash复制python clean_workspace.py demo-project

会看到扫描结果和“当前为预览模式”的提示。确认无误后再执行：

bash复制python clean_workspace.py demo-project --delete

输入 yes 后开始删除。这个脚本可以作为团队公共工具放到仓库里，也可以纳入本地开发前的准备工作。

4. 实战：把清理动作嵌入构建流程

4.1 前端项目：用 npm scripts 固化清理动作

前端项目的构建产物通常输出到 dist 或 build 目录。旧版本构建如果不清空，新的静态资源会直接混进去，可能造成 JS、CSS 文件不匹配。很多前端工程化工具本身不会自动清理输出目录，因此要在构建命令前加入清理步骤。

以 npm 项目为例，可以在 package.json 中定义：

json复制{
  "scripts": {
    "clean": "rimraf dist",
    "build": "npm run clean && npm run build:prod",
    "build:prod": "vite build"
  }
}

rimraf 是一个跨平台的删除工具，可以避免 Windows 下 rm -rf 不可用的问题。安装命令：

bash复制npm install --save-dev rimraf

后续团队成员只需要执行 npm run build，就会先清理 dist，再执行新的生产构建。开发时如果遇到“页面逻辑没更新”的问题，也可以先手动执行 npm run clean，排除旧产物干扰。

4.2 Java 项目：Maven 和 Gradle 的 clean 生命周期

Java 项目里最常见的错误是发布了“脏 jar 包”。所谓脏 jar，就是构建目录里残留了已经删除的类文件或资源文件，打包时被一起塞进去。

Maven 项目的标准命令是：

bash复制mvn clean package

clean 是一个独立的构建生命周期，它会删除 target 目录。先清理，再重新编译，最后打包。如果项目中使用多模块结构，建议在根目录执行：

bash复制mvn clean package -DskipTests

-DskipTests 只跳过测试执行，但会编译测试代码。如果想要连测试编译都跳过，可以写 -Dmaven.test.skip=true，实际项目中按团队要求选择。

Gradle 项目对应的命令是：

bash复制gradle clean build

clean 任务会删除 build 目录，build 任务会重新执行编译、测试、打包等生命周期。需要注意的是，构建工具本身不会在每次执行 package 前自动运行 clean，这个动作必须显式写在命令里，或者配置在 CI 脚本中。

4.3 服务端部署脚本：先备份再清理

服务端发布时，确保使用固定目录结构和固定发布路径非常重要。一个常见的发布流程是：备份当前版本，删除旧的可再生内容，放入新版本内容，启动前扫描残留。

下面是一个参考部署脚本 deploy.sh：

bash复制#!/usr/bin/env bash
set -euo pipefail

APP_HOME=/opt/app/myapp
RELEASE_DIR=/opt/releases/myapp-$(date +%Y%m%d-%H%M%S)

# 1. 准备新版本目录
mkdir -p "$RELEASE_DIR"

# 2. 备份当前版本，保留回滚可能
if [ -d "$APP_HOME" ]; then
    cp -r "$APP_HOME" "${APP_HOME}.bak.$(date +%s)"
fi

# 3. 只清理约定子目录，不要把整个 APP_HOME 删掉
cd "$APP_HOME"
rm -rf lib conf static

# 4. 放入新版本内容
cp -r "$RELEASE_DIR/lib" "$APP_HOME/lib"
cp -r "$RELEASE_DIR/conf" "$APP_HOME/conf"
cp -r "$RELEASE_DIR/static" "$APP_HOME/static"

# 5. 启动前扫描可疑遗留目录
find "$APP_HOME" -maxdepth 2 -type d \( -name "old-*" -o -name "*legacy*" -o -name "*.bak" \) -print

脚本里使用了 set -euo pipefail，一旦某条命令失败，脚本立即退出，避免带着半成品状态继续发布。需要特别注意的是，第 3 步只删除约定的 lib、conf、static 子目录，而不是对整个 APP_HOME 执行 rm -rf。这样能防止误删配置文件、数据目录或运行时需要的其他资源。

4.4 用 .gitignore 从源头避免“文件夹入库”

很多“文件夹没删”的问题其实发生在版本控制层面。开发者把本地的 target、dist、node_modules 等目录误提交到了 Git 仓库，其他人拉取代码后，残留文件就一直存在，即使执行了 clean 也删不掉跟踪文件，或者删除后又被重新拉取回来。

正确的做法是在项目根目录维护一份完整的 .gitignore：

gitignore复制# 构建产物
target/
dist/
build/
out/
*.class

# 依赖目录
node_modules/
.venv/
venv/

# IDE 与系统文件
.idea/
.vscode/
*.iml
.DS_Store

# Python 缓存
__pycache__/
*.pyc
.pytest_cache/

# 日志
*.log
logs/

如果旧目录已经被提交到仓库，需要先在版本库中停止跟踪，再提交 .gitignore：

bash复制git rm -r --cached target
git commit -m "chore: stop tracking build output directory"

注意，git rm --cached 只会把文件从 Git 索引中移除，本地工作区文件仍然保留，这样不会影响本地构建目录。对于需要永久清理历史提交记录的情况，可以使用 git filter-repo，但必须提前做好仓库备份，并在团队内部确认流程后再操作。

5. 实战：在 CI/CD 中保证干净构建

5.1 GitHub Actions 中的 clean 构建

本地构建可以靠命令约束，CI/CD 上更要采用“零信任”原则：不要假设上一个任务留下的目录是干净的，必须在流水线中显式执行清理。

下面是一个 GitHub Actions 的完整示例，以 Java Maven 项目为例：

yaml复制name: clean-build

on:
  push:
    branches: [ main ]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Set up JDK 17
        uses: actions/setup-java@v4
        with:
          java-version: '17'
          distribution: 'temurin'

      - name: Clean and package
        run: mvn clean package

      - name: Upload JAR artifact
        uses: actions/upload-artifact@v4
        with:
          name: app-jar
          path: target/*.jar

GitHub 托管的 runner 每次任务都会分配全新的工作环境，因此默认比较干净。但自托管 runner 因为复用工作目录，存在旧代码残留的风险。即使如此，流水线里显式写 mvn clean package 仍然是有价值的，因为 clean 保证了构建过程的确定性，而不是依赖 runner 环境“碰巧干净”。

5.2 自托管 Runner 与缓存带来的坑

自托管 runner 执行任务时，默认会复用上一次任务的工作目录。如果上一个分支构建留下了旧文件，下一次构建时 actions/checkout 默认行为是把当前仓库代码拉取进来，但不会完整清空无关目录。

解决方式是在 checkout 时显式开启 clean：

yaml复制- name: Checkout code
  uses: actions/checkout@v4
  with:
    clean: true

另外，依赖缓存也可能让构建“看起来没更新”。比如 Maven 仓库缓存 ~/.m2/repository，如果缓存 key 设计得太宽泛，可能复用旧的依赖包。更稳妥的做法是把依赖锁文件纳入缓存 key：

yaml复制- name: Cache Maven repository
  uses: actions/cache@v4
  with:
    path: ~/.m2/repository
    key: ${{ runner.os }}-m2-${{ hashFiles('**/pom.xml') }}
    restore-keys: |
      ${{ runner.os }}-m2-

pom.xml 变更时缓存 key 会变化，从而建立新的缓存，减少依赖版本错乱的概率。对于 Node 项目，可以直接用 package-lock.json 或 yarn.lock 的 hash。

5.3 发布产物审计：用清单和校验和发现残留

“文件夹没删”在构建阶段往往不会报错，但如果每次发布都生成产物文件清单，旧目录残留是可以提前暴露的。

在构建完成后执行：

bash复制cd target
find . -type f | sort > filelist.txt
sha256sum *.jar > checksums.txt

发布前把本次 filelist.txt 和历史版本进行比较。如果发现本次产物中出现了不应存在的目录或文件，说明构建清理有问题。比如上一个版本有 target/classes/com/example/OldService.class，而当前代码已经去掉了这个类，但本次产物清单里仍然有对应的 .class，那基本可以断定增量构建污染了产物。

对于前端项目，也可以生成静态资源清单：

bash复制cd dist
find . -type f -exec sha256sum {} \; > checksums.txt

把 checksums.txt 作为发布附件一起上传，运维发布时可以快速核对线上实际文件和构建产物是否一致。

6. 常见问题与排查思路

6.1 典型问题汇总

下面整理了一些“文件夹没删”引发事故后的常见表现、排查思路和处理方法：

6.2 一个典型的事故复盘过程

以一次后端服务“接口下线无效”的排查为例，整个过程可以帮助理解“残留目录”是如何影响线上行为的。

先描述现象：新版本已经下线的接口，在线上仍然能够正常访问，而且返回值是最旧的那套逻辑。常规思路是先看代码和配置中心，但代码确实是新代码，配置也已经改过，问题不在代码本身。

接着查看进程的启动参数和 classpath。发现 Spring Boot 应用的启动脚本里写了一个比较宽松的 classpath，比如 -cp lib/*:conf:classes。由于发布目录里同时存在 lib 和 classes，而 classes 目录里恰好残留了旧版的 .class 文件，JVM 加载时优先命中了旧类。

定位到具体文件后，处理方式分两步。第一步，临时修复：停止服务，清理 classes 目录，确认 lib 下没有旧 jar，再重启。第二步，根治：修改启动脚本，取消含义模糊的 classpath 配置，部署时保留固定发布路径，构建阶段强制使用 mvn clean package，并增加启动前的目录扫描步骤。

这类问题之所以耗时，不是因为命令复杂，而是因为“旧文件和新代码共存”在表现上很隐蔽。如果发布流程从一开始就把清理动作自动化，问题根本不会进入线上。

6.3 快速排查清单

如果怀疑线上存在残留目录问题，可以按以下顺序排查。

第一步，看启动日志。确认应用加载的资源路径、配置文件路径和 classpath 是否包含多个可疑目录。

第二步，扫描目录。用 find 查找常见的残留目录：

bash复制find /opt/app -maxdepth 3 -type d \( -name "target" -o -name "dist" -o -name "old-*" -o -name "*legacy*" \) -print

第三步，比对产物。把服务器上的文件清单和本次构建产生的 filelist.txt 做 diff，差异部分就是可疑对象。

第四步，检查版本库状态。执行 git status，看项目里是否混入了 target、node_modules、dist 等目录。

第五步，在测试环境复现。任何清理动作都不要直接在生产环境执行，先在测试环境验证影响范围。

7. 最佳实践：从工程机制上预防“漏删”

7.1 约定清晰的目录结构

项目从第一天就应该约定构建输出目录和发布目录的规范。前端统一输出到 dist，后端统一输出到 target 或 build，部署目录使用“版本号 + 时间戳”的目录，当前线上版本用软链接指向具体目录。

一个推荐的服务器目录布局是：

code复制/opt/app/releases/20250101-1200/
/opt/app/releases/20250102-0900/
/opt/app/current -> /opt/app/releases/20250102-0900/

新版本发布后，修改 current 软链接指向新目录，旧目录保留一定的时间窗口用于回滚。这种方式的优势在于：当前指向非常明确，不会出现多个版本同时在一个目录里互相干扰；回滚只需要改软链接；清理策略可以统一为“只保留最近 N 个版本目录”。

7.2 把清理动作固化到三层

第一层是开发阶段。执行 npm run clean 或 IDE 配置中的构建前清理，确保本地结果可复现。

第二层是构建阶段。Maven 项目使用 mvn clean package，Gradle 项目使用 gradle clean build，在 CI 脚本中显式写入清理命令。

第三层是部署阶段。使用 rsync --delete 可以同步目标目录，把源目录里没有的文件删除掉。示例：

bash复制rsync -av --delete ./dist/ /var/www/app/static/

--delete 会让远程目录与本地目录保持一致，多余文件会被删除。执行前先加 --dry-run 预览：

bash复制rsync -av --delete --dry-run ./dist/ /var/www/app/static/

这样既能清理旧文件，又能避免手写命令失误。

7.3 发布前检查清单

发布不是“提交代码后点一下构建”这么简单。建议按下面的检查清单走一遍。

第一，确认代码基于目标分支的最新版本，并检查锁定文件（package-lock.json、pom.xml 等）是否更新。第二，执行干净的构建命令，强制包含 clean 步骤。第三，核对产物文件清单，确认没有旧版本模块混入。第四，在测试环境完整部署一次，验证关键功能。第五，扫描服务器发布目录，确认不存在旧版本遗留目录。第六，确认配置来源正确，本地残留配置不会覆盖配置中心。第七，准备好回滚方案，保留前一个可运行版本。

7.4 安全与权限边界

清理脚本和部署脚本涉及删除操作，必须注意安全边界。

永远不要执行未经确认的 rm -rf，尤其是根目录、绝对路径和变量拼接路径。如果要在脚本中使用变量，先检查变量是否为空：

bash复制if [ -z "$APP_HOME" ]; then
    echo "APP_HOME 为空，拒绝执行"
    exit 1
fi

删除类工具要默认带预览模式，先输出将被删除的目录列表。发布账号应该拥有最小权限，只授权部署目录的读写权限，不授予系统级账号。清理动作先在测试环境试运行，确认没有影响再应用到生产环境。备份保留策略要明确，保证发布后可以快速回滚到上一个版本。

8. 结束语

网上那句“工程师偷懒，文件夹没删”，与其当成段子，不如当成一次提醒。残留目录不是磁盘洁癖问题，而是构建可重复性、发布可审计性、运行可预测性的问题。下次项目构建前，先跑一遍 clean；下次发布前，先扫一遍遗留目录；下次接手部署脚本时，别只打补丁式地修命令，把清理动作固化到脚本和流水线里。如果确认使用版本化发布目录和软链接切换，团队里很多“为什么改了没生效”的疑问会直接消失。