企业官网建设流程全解析

你是不是也遇到过这种情况：打开 PowerShell，光标停在C:\Users\你的用户名，然后每做一件事之前都得先输一遍cd D:\Work\xxx。一天下来，这个命令敲得比什么都熟。其实“PowerShell 设置默认读取某个文件夹”这件事，本质上不是让 PowerShell 去“读”某个目录，而是把它的默认工作目录改成你真正干活的地方。搞懂这个，你的终端体验能舒服不少，尤其是做开发、跑脚本、处理批量文件的时候，省下的可不止是几秒钟。

这篇文章我把背后的原理和几种实现方式都整理出来了。从最简单的改配置文件，到 Windows Terminal 的图形化设置，再到写一个可复用的函数，每个方案都附带了踩坑记录。不管你是刚接触 PowerShell 的新手，还是已经被默认目录烦了很久的老用户，都能找到适合自己的做法。

1. 先弄明白：你说的“默认读取某个文件夹”到底改的哪里

很多人一开始会把“默认读取文件夹”理解成“让脚本从这个文件夹里读文件”，或者“让 PowerShell 自动打开某个文件夹”。这里有个关键概念要澄清：PowerShell 本身是一个命令行环境，它有一个“当前工作目录”，也叫当前位置。所有不带绝对路径的命令、脚本引用、文件操作，都会默认以这个目录为起点。

1.1 工作目录是“根”，不是脚本文件夹

PowerShell 启动之后，工作目录默认来自哪里？对于普通双击快捷方式启动的powershell.exe，默认位置通常是用户主目录，也就是C:\Users\当前用户名。这继承自 Windows 为进程设置的工作目录。这个目录和 PowerShell 可执行文件所在的目录没有关系，和用户配置文件的目录也没有关系。

所以当你敲Get-Location，看到的是当前工作目录；敲Get-ChildItem，列出来的是这个目录下的文件。这就是“默认读取”的真相：你用相对路径读写东西时，相对的是它，而不是别的什么“安装目录”。

# 查看当前位置 Get-Location # 查看位置栈里的内容 Get-Location -Stack

如果你还不理解，可以把它想象成你手里拿着一个 GPS 导航仪，启动后它默认定在公司门口，你每次说“去附近的餐厅”，它找的都是公司附近的餐厅。你把导航仪的“默认位置”改成自己家，它才会在家附近找。PowerShell 的默认读取位置就是那个“导航仪的默认位置”。

1.2 常见的误区和需求分类

我在实际接触里发现，用户说“设置默认读取某个文件夹”一般有三类需求：

第一类是希望打开终端后，自动进入某个固定项目目录，比如D:\Project、E:\Code。第二类是希望某个脚本在运行时，能稳定地读取它自己旁边的文件，不受当前工作目录影响。第三类是希望把某个数据文件夹作为快捷操作的目标，比如默认读取日志文件所在目录。

这三类需求的解法不完全一样。第一类靠改启动配置；第二类靠$PSScriptRoot这类脚本级变量；第三类可能更适合封装函数或者使用环境变量。所以别急着搜教程，先想清楚你是哪一种。文章后面我会一个一个拆开讲，对应着做就不会跑偏。

2. 最推荐的做法：通过 $PROFILE 配置自动切换目录

先给结论：我个人最推荐的做法，是把工作目录切换命令写进 PowerShell 的配置文件（Profile）里。因为它的适用范围最广、逻辑最透明，而且改完以后不管你是从开始菜单打开，还是从某个集成终端里调起，都会生效。

2.1 找到并创建自己的 PowerShell 配置文件

PowerShell 启动时会自动执行一个脚本文件，这个文件就叫配置文件。不同宿主（比如编辑器里的 PowerShell 控制台、Windows Terminal、ISE）都有自己的 Profile 路径，但通常内容可以共用。你可以在任意 PowerShell 窗口里查看当前 Profile 路径：

$PROFILE

输出会是一串路径，常见是这样：

C:\Users\你的用户名\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1

注意，如果用的不是 Windows PowerShell 5.1，而是 PowerShell 7，路径里可能不是WindowsPowerShell，而是PowerShell\7。这个文件默认很可能不存在，所以要先创建。

# 如果目录不存在就创建 New-Item -ItemType Directory -Path (Split-Path $PROFILE) -Force # 创建空的配置文件 New-Item -ItemType File -Path $PROFILE -Force # 用记事本打开编辑 notepad $PROFILE

创建好之后，把切换目录的命令写进去即可。我建议写的时候多加一层判断，避免万一目录暂时不存在导致启动报错。比如：

$DefaultPath = 'D:\Work' if (Test-Path $DefaultPath) { Set-Location $DefaultPath }

这里Test-Path很关键，因为你可能在另一台机器上同步了这个 Profile，但该机器还没有D:\Work，不判断的话 PowerShell 每次启动都会飘红。

2.2 在配置文件里写入路径切换代码

很多人会直接在文件里写cd D:\Work，或者Set-Location D:\Work。这两种写法效果一样，但Set-Location是更正式的命令，cd只是它的别名。我习惯用Set-Location，因为在脚本里语义更清楚。

配置完成后，每次新开 PowerShell 窗口，当前目录都会自动变成D:\Work。这里有个细节：如果你之前已经开着 PowerShell，再改配置文件不会立即生效，必须重启新的会话。

另外一个实用小技巧，用Push-Location而不是Set-Location，会把原始目录压入一个位置栈。如果你希望以后能快速返回系统默认目录，可以在 Profile 里先记录一下：

$env:DefaultStartDir = (Get-Location).Path Set-Location $DefaultPath

这样以后想回到第一次启动时的目录，只需要执行Set-Location $env:DefaultStartDir。我在处理多个项目现场时经常用这个，比硬记路径方便多了。

2.3 别忘了处理执行策略

配置文件的本质是一个.ps1脚本，而 Windows 对运行 PowerShell 脚本有一套执行策略限制。如果你的机器默认是Restricted，那 PowerShell 启动时会因为无法加载配置文件而直接报错，或者干脆跳过。

验证方法很简单：

Get-ExecutionPolicy

如果看到Restricted，就需要放开到一个更友好的级别。我推荐使用RemoteSigned，意思是本地创建的脚本可以运行，从网络下载的脚本必须有签名。这样既满足了加载 Profile 的需求，又避免直接打开脚本地雷。

Set-ExecutionPolicy RemoteSigned -Scope CurrentUser

这里一定要加上-Scope CurrentUser，只影响当前用户，不要去动LocalMachine的全局策略，否则在某些企业环境下会引发权限问题。执行策略是有优先级的，CurrentUser能覆盖LocalMachine的默认设置，但又不会影响其他用户。

3. 不想改配置文件：从启动方式入手

有些人可能在公司电脑上没法随意改 Profile，或者嫌配置文件麻烦，那就直接从“怎么启动 PowerShell”下手。这类方案不依赖加载脚本，原理是修改启动进程的工作目录。

3.1 修改快捷方式的“起始位置”

如果你习惯从开始菜单或桌面的 PowerShell 快捷方式启动，可以这么改：

右键快捷方式，选“属性”，在“起始位置”一栏填上你想进入的文件夹，比如D:\Work，然后确定。以后再从这个快捷方式打开 PowerShell，工作目录就直接是D:\Work。

为什么这个有效？因为快捷方式定义里不但包含要运行的程序，还包含“工作目录”的初始参数。Windows 启动这个程序的时候，会优先把工作目录设置成你填写的路径。这其实是改动最小、最好理解的方法，非常适合不写代码的人。

需要注意，开始菜单里的快捷方式和任务栏固定的快捷方式可能是独立的。如果你改了开始菜单里的，任务栏那个没改，那点任务栏图标仍然回到旧目录。两个地方都检查一下比较稳妥。

3.2 Windows Terminal 里修改默认起始目录

现在很多人不再单独用 PowerShell 窗口，而是用 Windows Terminal。在 Windows Terminal 里，PowerShell 是一个“配置项”，而不是一个独立的进程入口，所以改系统自带 PowerShell 的快捷方式没有用，必须改 Windows Terminal 的配置文件。

打开 Windows Terminal，按Ctrl + ,进入设置，在左侧找到“配置文件”，选择 PowerShell 那一项，然后找“启动目录”（有的版本叫“起始目录”），填上D:\Work。保存后新开标签页就能生效。

如果 Windows Terminal 里的某个配置文件是从“命令提示符”继承过来的，路径要按现有配置填绝对路径，不填的话默认仍会是用户目录。我遇到过有的版本更新后，这个字段会被重置成空，所以如果你发现突然回到了C:\Users\用户名，来这里再看看。

3.3 用 bat 或其他启动器包装命令

这个方法更像是一种“曲线救国”：创建一个批处理文件，内容就是启动 PowerShell 并执行切换目录命令，以后统一用这个文件打开 PowerShell。

@echo off start "" powershell.exe -NoExit -Command "Set-Location -Path 'D:\Work'"

-NoExit参数的意思是执行完命令后不要关闭窗口，所以最终你会停留在 PowerShell 交互界面里，并且当前目录已经切换好。这个方法的好处是，即使忘了登入账户、没有配置 Profile，也一样能实现目录切换。

如果你想启动的是 PowerShell 7，就把powershell.exe改成pwsh.exe。注意在 Windows PowerShell 5.1 下，-WorkingDirectory这个参数不存在，所以用-Command配合Set-Location是通用做法。

4. 更稳更灵活：把“默认目录”做成一个可复用函数

如果你经常在不同项目之间切换，只固定一个目录一定不够。与其一遍遍改配置，不如把“默认目录”做成一整套可复用的逻辑，用的时候一条命令切过去。

4.1 在 profile 中定义工作目录函数

在$PROFILE里定义一个函数，把这些路径集中管理：

$ProjectRoots = @{ work = 'D:\Work' code = 'E:\Code' temp = 'D:\Temp' } function Go-Project([string]$Name) { if ($Name -and $ProjectRoots.ContainsKey($Name)) { $Path = $ProjectRoots[$Name] if (Test-Path $Path) { Set-Location $Path } else { Write-Warning "路径不存在: $Path" } } else { $ProjectRoots.GetEnumerator() | ForEach-Object { Write-Host ("{0,-10} -> {1}" -f $_.Key, $_.Value) } } }

保存后重启 PowerShell，以后只需要输入Go-Project work，就能直接切到D:\Work；不带参数直接输入Go-Project，会列出所有已配置的目录别名。这个思路特别像“快捷键收藏夹”。

这种做法的好处是，你不只解决了启动时默认目录的问题，还把日常切换目录的操作也统一优化了。你在实际用的时候，还可以往$ProjectRoots里加更多常用路径，而不需要每次都敲完整的cd命令。

4.2 脚本内部读取文件时用 $PSScriptRoot

前面说的都是“让 PowerShell 启动后默认在某个目录”，但还有一种场景经常被混淆：一个脚本文件放在某个文件夹里，读同一目录下的其他文件时，却被当前工作目录影响。

例如你有D:\Data\run.ps1，脚本里写了Get-Content "config.txt"。如果你启动 PowerShell 的默认目录是C:\Users\用户名，直接运行D:\Data\run.ps1，脚本会去读C:\Users\用户名\config.txt，而不是D:\Data\config.txt。

真正稳妥的写法是使用自动变量$PSScriptRoot，它表示当前脚本所在目录：

$configPath = Join-Path $PSScriptRoot 'config.txt' Get-Content $configPath

这种写法不受当前目录影响，才是真正意义上的“脚本默认读取某个文件夹”。我在写自动化脚本、定时任务时都坚持这个习惯，避免因为运行环境的目录不同而踩坑。

4.3 配合环境变量实现跨项目切换

如果你有多个项目，每个项目内部还有一些固定目录，你可以在 Profile 里定义环境变量，而不是简单的字符串。比如：

$env:MY_PROJECT = 'D:\Code\my-project' $env:MY_DATA = 'D:\Code\my-project\data'

后续任何脚本都可以用$env:MY_PROJECT来引用这个路径。这样就算项目整体搬走了，你也只需要在 Profile 里改一处，所有依赖它的脚本和函数全部自动更新。

这里有个小坑：环境变量在终端窗口里只是针对当前进程及其子进程的。如果脚本是在一个独立进程里启动，不要依赖你在另一个 PowerShell 窗口里设置的环境变量。需要持久化的环境变量，应该在“系统属性-环境变量”里设置，或者使用[Environment]::SetEnvironmentVariable(..., 'User')，但我个人不建议轻易改系统级环境变量，能用 Profile 就先用 Profile。

5. 常见问题排查与避坑速查

这部分是纯实战经验了。我在帮别人调 PowerShell 环境的时候，几乎每次都碰到下面几个问题。整理成速查表，你照着对就行。

5.1 配置文件写好了却不生效

先分清楚“没生效”是哪种情况。第一，配置文件路径不对。你可以输入$PROFILE查看实际加载的路径，把你编辑的内容保存到那个文件里，而不是编辑器随便打开的同名文件。第二，PowerShell 版本不对。Windows PowerShell 和 PowerShell 7 的 Profile 文件不互通，你改了 7 的，5.1 自然不会加载。第三，以-NoProfile方式启动的进程不会加载 Profile，比如某些自动化工具发出powershell -NoProfile -File xxx.ps1时，配置生效不了是正常的，别慌。

我建议用一个小命令快速确认当前会话是否加载了 Profile：

$profileLoaded = $MyInvocation.MyCommand.Path

如果输出为空，说明当前不是通过 Profile 加载的上下文；如果能看到 profile 路径，说明加载正常。

5.2 执行策略报错：禁止运行脚本

最常见的报错是：

无法加载文件 ...，因为在此系统上禁止运行脚本。

这就是执行策略问题。解决办法我刚才已经写过了，用Set-ExecutionPolicy RemoteSigned -Scope CurrentUser。如果你是在公司电脑上，受组策略管理，可能改了也改不回来。这时候可以用启动参数绕过，但不要把它写进脚本，只用于临时调试：

powershell.exe -ExecutionPolicy Bypass -NoProfile -File 你的脚本.ps1

要说明的是，Bypass只是跳过检查，不是修改策略。使用时要克制，尤其别把网上不明来历的脚本直接RemoteSigned跑起来，安全风险很高。

5.3 管理员和普通用户的 profile 不一样

PowerShell 打开时，“当前用户”是普通用户还是管理员，会影响$PROFILE的取值吗？不会，因为 Windows 的用户配置文件还是同一个。但如果你是用“以管理员身份运行”打开 PowerShell，UAC 会以提升后的令牌运行，而环境变量和路径通常还是一样。真正容易出问题的是一些第三方的模块和脚本在管理员和非管理员会话下行为不同。

比如，有些用户目录下的网络映射盘，在管理员窗口里可能映射不到，因为 UAC 隔离了权限。你要是发现 Profile 里写了Set-Location Z:\，普通窗口能进去，管理员窗口却报找不到路径，大概率就是这个原因。

5.4 升级 PowerShell 后的变化

如果你是从 Windows PowerShell 5.1 升级到 PowerShell 7（pwsh），有几点需要适应：第一，配置文件路径变了，默认是Documents\PowerShell\7\Microsoft.PowerShell_profile.ps1。第二，pwsh.exe支持一个新的启动参数-WorkingDirectory，意思是可以在启动时直接指定工作目录：

pwsh -WorkingDirectory D:\Work

这个参数特别适合配合 Windows Terminal 的配置，或者第三方编辑器集成。你可以在 Windows Terminal 的 PowerShell 7 配置项里，把“启动目录”留空，然后在启动参数里加这个选项，效果一样。第三，升级后别忘把原来的 Profile 迁移过去，很多旧模块不兼容，也一并排查下。

平时多留意终端的启动提示，PowerShell 7 启动时会打印一个版本行，如果你发现路径没变，多半是还没配置好。

结尾

回到开头说的那个场景。我自己刚接触 PowerShell 的时候，也烦过“每次打开都要先 cd”这件事。后来从改 Profile 到定义函数，再到把常用路径整理成菜单，才慢慢理解：工具的好坏，很大程度取决于你有没有花时间去调整它的默认行为。PowerShell 的默认目录只是一个很小的点，但它背后体现的是“让终端适应你的工作方式，而不是你迁就终端”。

最后一个建议：如果你准备入职一台新电脑，或者需要配置多台开发机，可以把你的 Profile 文件存到云笔记或者自己的代码仓库里。到新机器上直接拉下来，稍微改改路径就能用。那些踩过的坑，也会跟着这个文件一起变成你随身的工具包。