PowerShell 无法激活虚拟环境,执行 .\.venv\Scripts\Activate.ps1 后提示“在此系统上禁止运行脚本”,不等于虚拟环境里的 Python 已经坏了。先看完整报错,再确认能否直接调用环境中的解释器。
本文实测:在单独启动、采用 Restricted 执行策略的 Windows PowerShell 进程中,激活脚本被阻止;保持该策略不变,直接调用虚拟环境的 python.exe,成功运行 pip 和示例脚本。
三张配图是实际 PowerShell 子进程输出保存为日志后,在 VS Code 中打开的窗口截图,不是终端现场截图或客户案例。测试没有修改 CurrentUser、LocalMachine 或组织策略,前后读取的持久策略一致。
1. PowerShell 无法激活时,先读完整错误
本文对应的是 Activate.ps1 无法加载,并且错误中明确出现“禁止运行脚本”或英文 running scripts is disabled on this system 的情况。仅看到 UnauthorizedAccess 等尾部标识,不足以判断所有问题都来自同一个原因。
.\.venv\Scripts\Activate.ps1
在本次受限测试进程中,激活文件确实存在,但执行失败;进程返回码为 1。下面保留了实际错误和文件检查结果。

如果你的错误是“找不到路径”“不是可识别的命令”,先检查路径和当前目录;如果错误明确要求数字签名,也要按相应策略继续判断,不能直接套用本实验的 Restricted 原因。
2. 检查环境文件,再读取当前执行策略
以下命令在项目目录中执行,只检查文件和读取策略,不写入执行策略。假设虚拟环境目录名为 .venv;如果你的目录叫 venv 或其他名称,请相应替换。
Test-Path .\.venv\Scripts\Activate.ps1
Test-Path .\.venv\Scripts\python.exe
Get-ExecutionPolicy
Get-ExecutionPolicy -List
本次两个文件检查都返回 True。微软文档说明,Restricted 允许单条命令,但不允许脚本;Get-ExecutionPolicy -List 可查看各作用域的设置。组织策略也可能影响有效策略。参见微软执行策略说明。
文件检查为 False 时,不要先改策略。先确认是否位于正确的项目目录、虚拟环境是否创建完整。已有项目先核对环境用途,不要为了这条错误直接删除重建。
3. 不激活环境,直接调用其中的 Python
本次直接运行虚拟环境的解释器,打印路径,并用 sys.prefix != sys.base_prefix 判断当前解释器是否位于虚拟环境。这个命令没有运行 Activate.ps1。
& .\.venv\Scripts\python.exe -c "import sys; print(sys.executable); print(sys.prefix != sys.base_prefix)"
预期结果是解释器路径指向项目的 .venv\Scripts\python.exe,随后输出 True。本实验日志为了便于阅读使用相对路径;排查自己的项目时,上面的命令会显示完整路径。

Python 官方说明,使用虚拟环境并不要求先激活,可以直接指定环境中的解释器。激活主要帮助当前终端使用该环境的命令入口;是否真正运行在目标环境,应看解释器路径。参见 Python 官方虚拟环境说明。
路径中有空格时,可以保留 PowerShell 的调用运算符 &,并给完整路径加引号。下面只是路径格式示例,需要替换为你自己的实际位置。
& "C:\你的项目\.venv\Scripts\python.exe" --version
4. 用相同解释器运行 pip 和示例程序
继续使用同一个解释器检查 pip,不要换回不明确归属的全局 pip 命令。
& .\.venv\Scripts\python.exe -m pip --version
本次输出 pip 24.0,路径位于实验虚拟环境的 Lib\site-packages。接着创建一个放在项目目录中的 hello.py,内容如下:
print("Hello from venv")
print("sum:", sum([1, 2, 3]))
用相同解释器运行这个文件:
& .\.venv\Scripts\python.exe .\hello.py

这说明本实验中环境能够直接使用,并没有“修复”或放开激活脚本本身。之后仍需按同样方式验证你实际需要运行的脚本。第三方包、网络、GPU 等问题不在这个简单示例的验证范围内。
常见问题:下一步该处理哪个问题?
不出现 (.venv) 提示符,就一定没用到虚拟环境吗?
不是。直接指定解释器时,提示符可以不变;本实验已经用解释器路径和环境判断验证了目标环境。不要只依据提示符决定是否成功。
直接调用后出现 No module named 怎么办?
这时激活策略已经不是唯一问题,应检查该环境是否安装了项目需要的依赖。继续阅读 已安装包却提示 ModuleNotFoundError 的排查教程,确认装包与运行使用相同解释器。
终端这样能运行,VS Code 按钮却仍失败?
按钮可能使用不同入口。参考 VS Code 终端能运行、按钮报错的 5 步排查,比较解释器、执行文件和工作目录;不要把终端成功自动等同于编辑器入口已经配置正确。
直接调用 python.exe 也失败,还能继续照本文处理吗?
先保留新的完整错误。路径不存在、权限、环境损坏或其他应用控制限制,都需要单独判断。公司或学校设备应遵循管理员规定;本文的方法不保证在所有管理环境中可用。
为什么本文不提供一个统一的策略修改命令?
目标是先运行项目,且本次已有不修改执行策略的可验证办法。是否需要允许激活脚本,应结合设备管理要求和脚本来源另行决定,不能把一个设置当作所有激活问题的通用答案。
需要协助确认 PowerShell 与 Python 环境?
可以发送 Windows 版本、完整错误、两个 Test-Path 结果以及实际 Python 路径。截图前遮住账号、密钥和不希望公开的路径信息,不要发送密码或验证码。
先确认能否处理、范围和费用,再预约远程协助。已有环境故障或项目依赖排查需单独评估。
发送激活报错截图咨询查看 Python 基础环境安装服务实验说明
测试使用 Windows 构建 26200、Windows PowerShell 5.1.26100.8457、CPython 3.11.9 64 位与 pip 24.0。实验仅为专门启动的子进程指定 Restricted,未使用策略放宽命令。运行前后对持久作用域的策略列表进行对照,结果一致。测试环境名称和路径只是本机示例,其他 PowerShell 版本或组织管理环境的实际结果需另行确认。