企业官网建设流程全解析

C 盘又红了。做开发的人对这条提示都不会陌生，而且这两年明显感觉“红”得比以前更快了。以前装个 IDE、几个虚拟机、一堆 npm 包，C 盘还能勉强撑住；现在 AI 编程工具成了每天的刚需，它们不只是安装包占空间，更会在运行过程中不断写缓存、写会话记录、写日志，几天不动就能吃掉几个 GB。

很多人的第一反应是上分区工具，把 D 盘的空间匀给 C 盘。但这属于“硬操作”，风险高不说，还得重启进 PE 环境，万一操作到一半断电就麻烦了。更稳妥的思路其实是软迁移：把那些可以移动的数据，从 C 盘搬到 D 盘。

这篇文章要解决的，就是“AI 开发工具吃光 C 盘”这个问题。我会以 OpenAI 开源的终端编程助手 Codex 为例，完整演示如何把它的主目录、缓存、npm 全局包、插件和定时清理自动化全部迁到 D 盘，同时把 Docker Desktop、Ollama、浏览器缓存这些常见的“C 盘大户”一并讲清楚。读完这篇文章，你不需要动分区表，也能给 C 盘腾出可观空间。

1. 这篇文章真正要解决的问题

先说结论：C 盘紧张，大多数时候不是“装的东西太多”，而是“累积的数据太多”。

普通软件安装后，程序本体是固定的，占多少就是多少。但开发工具不一样，它们会持续产生运行期数据。Codex 这类 AI 编程助手尤其明显：

• 每个交互会话都会在本地保存上下文记录；
• 每天的运行日志不断增长；
• 模型返回内容的本地缓存、临时文件反复写入；
• 通过 npm 安装的全局包、依赖和插件分布在用户目录；
• 如果你同时还在用 Docker Desktop、Ollama、VS Code，数据量还会指数级上升。

这些数据默认都在 C 盘的用户目录下。日积月累，C 盘从“还有空间”到“飘红告急”，往往只需要一两个星期。

这篇文章适合谁？适合所有在 Windows 上做开发、C 盘空间紧张、又不想冒险动分区的开发者。无论你用的是 Codex、Docker、Ollama，还是只装了 VS Code 和一堆插件，这篇文章的思路都可以直接复制。核心方法就一句话：把默认落在 C 盘的数据目录，通过迁移和符号链接的方式，重定向到 D 盘。

这样做的好处有三点：

1. 不动系统盘的分区结构，风险可控；
2. 对工具本身完全透明，它们以为自己还在原目录运行；
3. 迁移失败可以随时回滚，不会造成数据丢失。

2. Codex 的空间都去哪儿了

在动手迁移之前，先弄清楚一件事：Codex 到底把数据写在哪里？如果连空间是哪里被占的都不知道，盲目清理很可能误删重要数据。

Codex CLI 作为一款终端 AI 编程助手，安装方式主要有两种：一种是 npm 全局安装，另一种是官方原生安装包。但无论哪种方式，它的用户数据几乎都集中在~/.codex目录下，在 Windows 上也就是C:\Users\你的用户名\.codex。

这个目录里的内容大致如下：

看到问题了吗？config.toml和auth.json只占几百 KB，真正可怕的是sessions、log和cache。Codex 每次和模型交互，都会把带上下文的会话内容写入本地，一个长会话可能就有几 MB 到几十 MB。如果你每天都高强度使用，一个月积累几个 GB 非常正常。

除了.codex目录，还有一块空间容易被忽略：npm 全局包。用npm install -g @openai/codex安装时，包本身和它的依赖都会放进 npm 的全局目录，默认是C:\Users\你的用户名\AppData\Roaming\npm或者 Node.js 安装目录。Codex 本身不算大，但它的依赖树加上其他全局工具（比如typescript、eslint、各种 CLI），加起来也是不小的开销。

最后是插件。Codex 的插件生态还在快速发展中，常见的形式有自定义技能（skills）、提示词扩展、以及和编辑器联动的插件。插件本体不大，但它们往往带着自己的依赖和数据目录，同样默认落在 C 盘。

所以，如果你运行codex一段时间后发现 C 盘越来越少，不要奇怪。它不是在“泄漏”，而是把每次工作的痕迹都完整保存在本地。这种设计对可追溯性有好处，但对磁盘空间不友好。解药就是把它们整体搬走。

3. 迁移前准备与方案选型

迁移不是拷贝文件那么简单。Windows 上很多工具会硬编码地去用户目录找数据，直接搬走，工具就找不到配置了。所以要提前想清楚方案。

3.1 先做盘点和备份

迁移前，先确认这几件事：

1. 当前 Codex 版本是多少？可以运行codex --version查看。
2. .codex目录现在有多大？
3. D 盘是否有足够的剩余空间？
4. 是否有重要会话记录和自定义配置需要保留？

然后做一次完整备份。备份最简单的方式是把.codex整个目录复制到 D 盘，或者用压缩工具打包。这步不能省，因为后续所有操作都建立在“数据安全有兜底”的前提下。

# 查看 C 盘剩余空间 Get-PSDrive C | Select-Object Used, Free # 查看 .codex 目录大小 $codexDir = "$env:USERPROFILE\.codex" $size = (Get-ChildItem $codexDir -Recurse -Force | Measure-Object -Property Length -Sum).Sum "{0:N2} GB" -f ($size / 1GB) # 备份到 D 盘 Copy-Item $codexDir "D:\Backup\codex-backup" -Recurse -Force

这里要说一个重要原则：不要在迁移过程中删除原目录，直到新路径验证通过。

3.2 三种迁移方案对比

Windows 下把工具数据迁移到 D 盘，主流方案有三种：

对于 Codex，目前它的配置文件路径虽然有环境变量可覆盖（具体以你使用的版本为准），但最通用的做法还是目录联接。

目录联接的底层原理是 NTFS 的重解析点（reparse point）。当 Codex 尝试访问C:\Users\你\.codex时，Windows 文件系统会把这个路径“透明地”指向D:\DevTools\codex。对 Codex 来说，路径没有变化，它照样读写；对系统来说，实际数据全部落在 D 盘。

推荐步骤概括为：

1. 复制.codex到 D 盘；
2. 把 C 盘原目录改名为.codex_bak；
3. 用mklink /J在 C 盘创建指向 D 盘的联接。

这个方案既保留回滚能力，又对工具透明，尤其适合 Codex、Docker 这类“认死路径”的工具。

4. 核心实操：把 Codex 主目录搬到 D 盘

下面进入具体操作。我的建议是：每执行一步都验证一步，不要一口气跑完所有命令。

4.1 关闭 Codex 相关进程

迁移前必须确保没有进程正在读写.codex目录，否则文件可能被占用，复制不完整。

# 查看是否有 codex 相关进程 Get-Process | Where-Object { $_.ProcessName -like "*codex*" } # 如果有，先结束进程 Stop-Process -Name "codex" -Force -ErrorAction SilentlyContinue

如果 Codex 是通过 VS Code 的集成终端运行的，建议先关闭所有终端窗口。

4.2 复制数据到 D 盘

使用robocopy而不是普通的Copy-Item。原因在于robocopy支持多线程、断点续传和完整的属性复制，适合大规模目录迁移。

robocopy "$env:USERPROFILE\.codex" "D:\DevTools\codex" /E /COPYALL /DCOPY:DAT /R:2 /W:2

参数说明：

• /E：复制所有子目录，包括空目录；
• /COPYALL：复制文件数据、属性、时间戳、安全信息；
• /DCOPY:DAT：复制目录属性；
• /R:2 /W:2：失败重试 2 次，每次等 2 秒，避免长时间卡住。

robocopy的退出码比较特殊：0 到 7 都算成功，8 及以上才表示有错误。所以不要用普通的“命令出错返回非 0”来判断结果，要看具体退出码。

4.3 重命名原目录并创建联接

复制完成后，不要直接删除原目录。建议先改名保留，等验证通过后再删。

ren "%USERPROFILE%\.codex" "%USERPROFILE%\.codex_bak" mklink /J "%USERPROFILE%\.codex" "D:\DevTools\codex"

注意mklink是 CMD 内置命令，在 PowerShell 里直接运行会提示无法识别。可以在 PowerShell 里调用cmd /c，或者直接用 CMD 窗口执行：

cmd /c mklink /J "%USERPROFILE%\.codex" "D:\DevTools\codex"

/J参数表示创建目录联接（junction），不需要管理员权限；/D是符号链接（symlink），通常需要管理员权限。这里优先用/J。

4.4 验证迁移结果

验证分两步：第一步看链接是否建好，第二步看 Codex 是否还能正常运行。

# 查看目录链接状态 Get-Item "$env:USERPROFILE\.codex" | Select-Object FullName, LinkType, Target

如果LinkType显示Junction，Target指向D:\DevTools\codex，说明链接创建成功。

然后运行 Codex，随便发起一次简单对话，确认它能正常读写配置和会话记录：

codex exec "回复：迁移测试"

运行正常后，可以再回 D 盘查看sessions目录，确认新会话确实写到了 D 盘。

到这里，Codex 主目录的迁移就完成了。原目录.codex_bak先留着，等使用一周确认没有问题再删除。

5. 把 npm 全局包和缓存也搬走

很多人在搬完 Codex 之后，发现 C 盘并没有宽裕太多。原因很可能是 npm 的全局目录和缓存还留在原处。如果你当初是用npm install -g @openai/codex安装的 Codex，那 npm 的全局包目录就是另一个“隐藏大户”。

5.1 查看当前 npm 全局目录

npm config get prefix npm config get cache

在 Windows 上，prefix默认一般是C:\Users\你的用户名\AppData\Roaming\npm，cache默认在C:\Users\你的用户名\AppData\Local\npm-cache。两个目录加起来，少说有一两个 GB，如果全局包装得多，几个 GB 也很常见。

5.2 修改 npm 全局目录和缓存位置

先创建目标目录，然后把 prefix 和 cache 都修改到 D 盘。

mkdir D:\DevTools\nodejs\npm-global mkdir D:\DevTools\npm-cache npm config set prefix "D:\DevTools\nodejs\npm-global" --location=global npm config set cache "D:\DevTools\npm-cache"

注意：新版 npm（9 及以上）对全局配置有更严格的限制，需要使用--location=global才能修改全局的 prefix。如果直接设置报错，就加上这个参数。

5.3 修改 PATH 环境变量

改了 prefix 之后，原来在 PATH 里的C:\Users\你的用户名\AppData\Roaming\npm就不再是新的全局包位置了。需要把新位置加入用户 PATH，否则在终端里找不到codex等全局命令。

$oldPath = [Environment]::GetEnvironmentVariable("Path", "User") [Environment]::SetEnvironmentVariable("Path", $oldPath + ";D:\DevTools\nodejs\npm-global", "User")

修改完成后，重新打开一个终端窗口，运行npm config get prefix确认已经是新路径。

5.4 重新安装全局包

这里有个很多人踩过的坑：直接复制旧的全局 node_modules 到新目录，往往会出现路径硬编码问题，导致命令能用但内部依赖报错。更安全的方式是记录旧包列表，然后重新安装。

# 先记录旧的全局包 npm ls -g --depth=0 > D:\DevTools\codex-backup\global-packages.txt # 在新 prefix 下重新安装 npm install -g @openai/codex npm install -g typescript ts-node

重新安装后，运行codex --version，如果正常输出版本号，说明新的全局环境已经可用。此时旧的AppData\Roaming\npm目录可以留作备份，确认无问题后再手工清理。

6. 插件与编辑器相关数据的迁移

Codex 的插件，以及和它配套使用的 VS Code 扩展、浏览器缓存，同样在悄悄占用 C 盘。这部分迁移要分情况处理。

6.1 Codex 插件目录

在把.codex整体迁移到 D 盘时，插件目录已经跟着走了。这里需要确认的是插件配置里的路径引用。有些插件会在自己的配置里写死绝对路径，比如指向C:\Users\...。迁移后打开插件配置检查一遍，把涉及旧路径的地方改成新路径。

Codex 的配置文件在config.toml，如果配置了自定义模型提供商或插件目录，类似这样：

model = "gpt-5-codex-mini" model_provider = "openai" [model_providers.openai] name = "OpenAI" base_url = "https://api.openai.com/v1" env_key = "OPENAI_API_KEY" wire_api = "responses"

这里并不是让你照抄这个配置，而是想说明：Codex 的核心配置都在config.toml里，迁移后如果发现某些功能异常，优先检查这个文件中的路径类配置项。具体的插件和模型提供商配置格式，以你安装的 Codex 版本官方文档为准。

6.2 VS Code 扩展目录

如果你主要通过 VS Code 使用 Codex，那 VS Code 扩展目录也不是小数目。默认位置是C:\Users\你的用户名\.vscode\extensions，装了几十个扩展之后轻松超过 1 GB。

把扩展目录迁到 D 盘，可以给 VS Code 的启动快捷方式加上参数：

"D:\DevTools\VSCode\Code.exe" --extensions-dir "D:\DevTools\VSCode\extensions"

完整步骤如下：

1. 关闭所有 VS Code 窗口；
2. 复制C:\Users\你的用户名\.vscode\extensions到D:\DevTools\VSCode\extensions；
3. 修改 VS Code 快捷方式的目标，加上--extensions-dir参数；
4. 启动 VS Code，在扩展面板确认已安装扩展仍然可见。

如果觉得改快捷方式麻烦，也可以写一个启动脚本：

# 文件路径：D:\DevTools\VSCode\start-code.ps1 Start-Process "D:\DevTools\VSCode\Code.exe" -ArgumentList '--extensions-dir "D:\DevTools\VSCode\extensions"'

之后统一从脚本启动 VS Code。

6.3 浏览器缓存

Edge 和 Chrome 的缓存也是 C 盘空间的重要消耗者。浏览器的缓存目录本来就应该允许被随时清理，如果不想每次手工清理，可以直接把缓存目录迁移到 D 盘。

Chrome 的启动参数：

"C:\Program Files\Google\Chrome\Application\chrome.exe" --disk-cache-dir="D:\DevTools\Chrome\Cache"

Edge 的启动参数类似：

"C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe" --disk-cache-dir="D:\DevTools\Edge\Cache"

需要说明的是，浏览器缓存迁移的意义在于“不再让缓存挤占 C 盘”，但它本身还是能随时清空的重建数据。相比之下，Codex 的会话记录和日志如果误删是无法恢复的，所以迁移的重点始终应该放在 Codex、Docker 这类不可再生数据上。

7. 自动化：定时清理脚本和空间告警

迁移完目录，只是治标。如果不建立自动化机制，C 盘还是会慢慢被新的日志和缓存填满。这一节讲两个自动化：定时清理和空间告警。

7.1 写一个 Codex 缓存清理脚本

Codex 的会话记录和日志是有保留价值的，但没必要无限期保留。合理的策略是：日志保留 30 天，会话记录保留 90 天，超过期限自动清理。

# 文件路径：D:\DevTools\scripts\clean-codex-cache.ps1 $codexDir = "D:\DevTools\codex" $logDir = Join-Path $codexDir "log" $sessionDir = Join-Path $codexDir "sessions" $cacheDir = Join-Path $codexDir "cache" # 清理超过 30 天的日志 if (Test-Path $logDir) { Get-ChildItem $logDir -File -Recurse -ErrorAction SilentlyContinue | Where-Object { $_.LastWriteTime -lt (Get-Date).AddDays(-30) } | Remove-Item -Force -ErrorAction SilentlyContinue } # 清理超过 90 天的会话记录 if (Test-Path $sessionDir) { Get-ChildItem $sessionDir -File -Recurse -ErrorAction SilentlyContinue | Where-Object { $_.LastWriteTime -lt (Get-Date).AddDays(-90) } | Remove-Item -Force -ErrorAction SilentlyContinue } # 清理 7 天前的临时缓存文件 if (Test-Path $cacheDir) { Get-ChildItem $cacheDir -File -Recurse -ErrorAction SilentlyContinue | Where-Object { $_.LastWriteTime -lt (Get-Date).AddDays(-7) } | Remove-Item -Force -ErrorAction SilentlyContinue } Write-Host "[$(Get-Date)] Codex 缓存清理完成"

这个脚本执行前，请确认 Codex 没有在运行。如果正在运行，目录里的文件可能被占用，清理会失败。脚本也做了静默错误处理，不会因为单个文件占用就中断。

7.2 用计划任务定时执行

Windows 的计划任务可以用schtasks创建。下面创建一个每周日凌晨 2 点执行的清理任务：

schtasks /Create /TN "CodexCacheCleanup" /TR "powershell.exe -ExecutionPolicy Bypass -File D:\DevTools\scripts\clean-codex-cache.ps1" /SC WEEKLY /D SUN /ST 02:00 /F

/SC WEEKLY /D SUN /ST 02:00表示每周日 02:00 执行一次。凌晨执行的好处是基本不会和开发工作时间冲突。

7.3 加一个 C 盘空间告警

清理脚本只能在空间满了之后“亡羊补牢”。更好的做法是提前发现趋势：当 C 盘剩余空间低于某个阈值时，自动提醒你。

# 文件路径：D:\DevTools\scripts\check-c-disk.ps1 $drive = Get-PSDrive C $freeGB = [math]::Round($drive.Free / 1GB, 2) $thresholdGB = 20 if ($freeGB -lt $thresholdGB) { Write-Host "[警告] C 盘剩余空间不足：${freeGB} GB，请检查是否需要迁移或清理。" -ForegroundColor Red # 这里可以接入企业微信机器人、钉钉机器人或邮件通知 } else { Write-Host "[正常] C 盘剩余空间：${freeGB} GB" }

这个脚本同样可以加入计划任务，每天早上执行一次，做到对 C 盘空间心中有数。

8. 关联案例：Docker Desktop 与 Ollama 的迁移

如果你同时使用 Docker Desktop 和 Ollama，C 盘告急几乎是必然的。Docker 的虚拟磁盘镜像默认在C:\Users\你的用户名\AppData\Local\Docker\wsl下，一个ext4.vhdx文件动辄几十 GB；Ollama 的大模型默认存在C:\Users\你的用户名\.ollama\models，一个模型就是几个 GB。

这两块的迁移逻辑和 Codex 一样：把数据目录移到 D 盘，再告诉工具去新的位置找数据。

8.1 Docker Desktop 修改数据目录

新版 Docker Desktop 推荐直接在界面操作：

1. 打开 Docker Desktop 设置；
2. 进入 Resources -> Advanced；
3. 修改 Disk image location 为 D 盘路径，例如D:\Docker\data；
4. 点击 Apply & Restart。

如果界面里找不到这个选项，也可以直接修改 Docker Desktop 的settings.json文件，里面有一个dataFolder字段：

{ "dataFolder": "D:\\Docker\\data" }

settings.json的位置一般在C:\Users\你的用户名\AppData\Roaming\Docker\settings.json。修改之前，务必先关闭 Docker Desktop，并且确认 D 盘空间足够容纳整个数据目录。

8.2 Ollama 修改模型存储目录

Ollama 支持通过环境变量OLLAMA_MODELS指定模型存放目录。迁移步骤如下：

# 关闭 Ollama Stop-Process -Name "ollama" -Force -ErrorAction SilentlyContinue # 复制模型目录 Copy-Item "$env:USERPROFILE\.ollama" "D:\DevTools\ollama" -Recurse -Force # 设置环境变量 setx OLLAMA_MODELS "D:\DevTools\ollama\models"

设置完环境变量后，重新启动 Ollama，运行ollama list确认模型列表还能正常显示。如果模型没有出现在列表里，检查新目录下models文件夹是否存在，以及环境变量是否真的生效。

这里有个容易忽略的坑：setx设置的环境变量只对之后启动的进程生效，正在运行的终端窗口里是读不到的。设置完一定要新开终端，再启动 Ollama。

9. 常见问题与排查方法

迁移过程中最容易出问题的不是拷贝，而是“工具找不到数据”和“旧路径残留”。下面把高频问题集中列出：

在排查任何迁移问题时，通用顺序是：先确认目标目录的文件完整，再确认链接或环境变量生效，最后确认软件是在新配置下启动的。大部分问题出在第三步。

10. 最佳实践与工程建议

迁移一次容易，但想把 C 盘长期维持在一个安全水位，需要养成几个习惯。

10.1 建立“数据目录清单”

给自己维护一份清单，记录所有迁移到 D 盘的数据目录：

这份清单最大的价值是：下次重装系统或者换电脑时，可以照着清单快速恢复环境，不用再一个个排查。

10.2 迁移前备份、迁移中验证、迁移后回滚

每次迁移都要遵循三个原则：

1. 迁移前备份：用robocopy或压缩工具把原目录完整复制一份；
2. 迁移中验证：每完成一步，立即用工具的实际功能验证结果；
3. 迁移后回滚：原目录不要立刻删除，改名保留至少一周。如果发现问题，删除联接、把备份目录改回原名即可恢复。

10.3 权限与安全边界

修改环境变量和创建目录联接时，尽量使用当前用户权限，不要随意“以管理员身份运行”，更不要修改系统级的 PATH 或系统盘的系统目录。Codex 的auth.json里保存着登录凭证，迁移后要确保 D 盘目录的访问权限正常，不要把整个目录设为“所有人可读”。

10.4 日志和监控优先于“手动清理”

手动清理的问题在于：你总是会忘记。更合理的做法是让计划任务定期执行清理脚本和空间检查。刚开始可以每周检查一次运行日志，确认清理脚本没有误删重要文件，再逐步把周期拉长。

11. 最后说几句

Codex 本身不复杂，安装也就是一条命令的事。真正让它显得“重”的，是随使用时长不断累积的会话记录、日志和缓存。把这些数据从 C 盘软迁移到 D 盘，不改变工具的使用体验，却能实实在在地缓解系统盘的生存压力。

这篇文章提供的所有命令和脚本，建议收藏备用。等哪天 C 盘再次告急，不用去网上重新搜索“怎么清理 C 盘”，直接打开这篇文章，按顺序执行一遍就能解决问题。

迁移完成之后，你还会发现另一个好处：以后重装系统，只要 D 盘数据还在，Codex 的配置、会话记录和插件都能直接恢复，省去的重新配置时间远超迁移本身。这也算是 C 盘告急带来的一点意外收获。