关于 Powershell 的配置的一次经历

前言

我的博客部署之前说过，是通过 git 工作流完成的：

• Blog-Source 分支存放源文件
• main 分支存放生成的静态页面
• CI/CD 监听 Blog-Source 的 push，自动跑 hexo g 然后部署到 main

为了方便，我就加了一个 git add && git commit && git push 的 alias powershell 函数，名为 blogdeploy。

但是其实这个是新版，之前没有这套 workflow 的时候，我的 blogdeploy 就是 hexo g 之类的。

然后，我因为考虑实际需求，想在最前面又加一个 git pull，但是懒得自己看（而且其实我也不懂 powershell 对吧），就把需求交给 Agent 了。

然后就出现了下面奇异搞笑的事情：

1. 看错文件

AI 帮我搜索 $PROFILE，在 ~\Documents\WindowsPowerShell\ 下面找到了一个 Microsoft.PowerShell_profile.ps1，里面确实有 blogdeploy，内容是：

function blogdeploy {
    cd "C:\Users\endle\hexo-blog"
    hexo clean
    hexo g
    hexo d
}

根本没有 git 操作。而且跟我的印象完全不符，因为我记得跑 blogdeploy 的时候看到的是 git commit / push 的输出。

但是 AI 还是帮我加上了 git pull。

这我再跑的时候才发现输出大概是这样的：

🚀 提交并推送...
[Blog-Source 863d366] Site updated: 2026-06-21 00:27:14
...
To https://github.com/wendaining/wendaining.github.io.git
   Blog-Source -> Blog-Source
✅ 推送完成！CI 将自动编译部署。

和我印象也没差，但是 git pull 根本就没加上去。

2. 找到问题

重新排查才发现问题所在：我之前设置 Windows 把 Documents 文件夹重定向到了 D 盘：~\Documents → D:\UserFolders\Documents。

而 PowerShell 其实有两套互不相干的配置文件体系：

	Windows PowerShell 5.1	PowerShell 7 (pwsh)
配置文件目录	Documents\WindowsPowerShell\	Documents\PowerShell\
实际路径	D:\UserFolders\Documents\WindowsPowerShell\	D:\UserFolders\Documents\PowerShell\

我用的是 PowerShell 7，所以真正的配置在 PowerShell\ 目录下。而 AI 找到的 WindowsPowerShell\ 下面那个是早期用 Windows PowerShell 5.1 时留下的旧版本，早就废弃不用了。

真正的 blogdeploy 其实一直长这样：

function blogdeploy {
    cd "C:\Users\endle\hexo-blog"
    # git add → commit → push → CI 自动部署
    git add .
    git commit -m "Site updated: $currentTime"
    git push origin Blog-Source
}

从来没有 hexo clean/g/d，那些都在 CI/CD 里跑。

3. 总结

由三个因素叠加造成：

1. Documents 重定向 — C:\Users\{Username}\Documents 映射到 D:\UserFolders\Documents，AI 初次搜索没有交叉验证，没有使用 $PROFILE 变量，而是猜路径。
2. PowerShell 双版本 — PowerShell 5.1 和 PowerShell 7 各自有一套独立的 profile 路径，彼此无交集
3. 旧配置没清理 — 早期用 Windows PowerShell 5.1 时写的 hexo 版本 blogdeploy 一直残留在旧路径里，等到换成 PW7 后重新写了 git 版本，旧的一直没删

在正确的文件（D:\UserFolders\Documents\PowerShell\Microsoft.PowerShell_profile.ps1）里面加上就解决了问题：

function blogdeploy {
    cd "C:\Users\endle\hexo-blog"

    Write-Host "🔄 拉取最新代码..." -ForegroundColor Cyan
    git pull

    if ($LASTEXITCODE -ne 0) {
        Write-Host "❌ git pull 失败，请检查冲突或网络。" -ForegroundColor Red
        return
    }

    # ... 后续 git add / commit / push
}

同时删除了 WindowsPowerShell 下那个早已废弃的 hexo 版 blogdeploy。

4. 但其实还没完

我其实就比较好奇，我明明通过"右键 → 属性 → 位置"把 Documents 迁移到了 D 盘，为什么 C 盘还有一个 Documents 目录，而且里面还有文件？

下面发现才是 Windows 的奇异搞笑的史山。

Windows 的文件夹重定向机制非常简单粗暴：

迁移前： ~\Documents  ← 实际存储
迁移后：  D:\UserFolders\Documents       ← 实际存储（注册表指向这里）
          ~\Documents  ← 空壳，物理目录残留

关键细节：Windows 不会在旧路径创建符号链接。旧的 C:\Users\<用户名>\Documents 目录就留在了那里，退化成一个普通文件夹。

其实规范的做法是走 Shell API，查注册表得到目前真正的 Documents 目录。

但是，就连微软家不少产品的做法（如 VS）都是直接硬编码路径 $env:USERPROFILE + "\Documents"，而不是查 API，这就导致了这些软件一直往那个根本不对的路径里面写文件。