简介：这份便携式编程环境面向需要频繁更换电脑、在公共机房或移动办公场景下快速开展 Python 开发的用户，集成 VSCode 编辑器、WinPython 解释器、中文界面与 pip 扩展库，解压后即可使用，也可放入 U 盘随身运行，省去重复配置 Python 环境的步骤。压缩包共约 2000 个文件，整体大小 250.75MB，内容以 py 脚本、json 配置、js 资源、txt 与 md 说明文档为主，并包含 css、html 等辅助文件，基本覆盖编辑器运行、解释器组件和扩展库所需结构。目前已有 136 人学习或下载。其价值在于把编辑、调试、包管理与科学计算常用依赖整合到同一便携目录中，WinPython 的环境隔离特性可避免影响本机既有 Python 配置，pip 也可继续安装所需库；同时兼容 X86/X64 Windows 系统，适合在不同电脑间迁移开发环境、快速验证脚本和保持项目依赖一致，对初学者和需要轻量部署的开发者都较为实用。

1. 从一台装不了 Python 的机器说起：vscode 便携版加 winpython 便携版

有一次在一台不让改系统环境的机器上做数据核对，Python 装到一半就被拦了，理由是不能写系统目录、不能改 PATH。那天下午我换了个思路：把vscode 便携版和winpython 便携版解压进一个 U 盘，插上去，双击，十分钟后代码就跑起来了。这套组合在离线场景里出镜率很高——机房、教学机、驻场笔记本，凡是“装不了环境”或者“装了也带不走”的地方，它都能顶上。

它不是“绿色版”三个字那么简单。目录层级摆错、盘符一变、pip 装到宿主机上，随便哪一条都能让人当场卡住。X86/X64 也不能凭感觉选。下面这套流程，是我踩完之后固定下来的顺序。

2. 选型先定三件事：WinPython 3.11 与 3.12 分支、X86/X64、目录层级

动手解压之前，有三件事必须先定下来，否则后面改起来很麻烦。这三件事互相关联：选了哪个 Python 分支，决定了你能用哪些轮子；选了三十二位还是六十四位，决定了哪些包根本装不上；目录摆在哪里，决定了换一台机器之后整套东西还能不能活。

2.1 WinPython 的版本分支：3.11 与 3.12 该选哪一支

WinPython 本质上就是把一份 CPython 解释器、一批预编译好的科学计算轮子、几个启动器（Spyder、Jupyter、Control Panel）打成一个自解压包或 zip 包。它的版本线跟着 CPython 走，所以“选 WinPython 版本”约等于“选 Python 版本”。

3.12 分支最需要注意的一点是distutils被移除。很多老项目的setup.py里明晃晃写着from distutils import ...，在 3.12 下会直接报ModuleNotFoundError: No module named 'distutils'。而便携环境往往恰恰是在没网的机器上装一些年头不短的内部包，撞上这个概率不低。除此之外，3.12 对 C 扩展的构建链也有调整，一部分轮子还没跟上，pip install会退化成源码编译，接着就撞上编译器缺失。

3.11 分支的生态成熟度更高，绝大多数科学计算轮子都有现成的cp311二进制包，pip install基本是下载即用，不需要本机装编译工具链。我一般默认选 3.11，只有在明确要用的库硬性要求>=3.12时才换。

还有一个坑在更老的机器上：CPython 从 3.9 起就不再支持 Windows 7 了。如果目标机器是 Win7，3.11 和 3.12 都装不上，只能退到 3.8 那一支，代价是不少新库也用不了。这个前提要先问清楚，别到了现场才发现。

至于包的类型，WinPython 常见的有三类：

便携场景选完整版。理由很实在：目标机器很可能没网，而完整版里 numpy、pandas 这些常用库已经躺在site-packages里了，插上就能import，省掉一整套离线搬运的功夫。

2.2 X86 与 X64 不是看机器新旧，是看轮子和扩展

很多人以为“机器是新的就选 64 位”，这话对一半。现在绝大多数 x64 机器当然应该跑 64 位包，但选三十二位的真实理由从来不是机器老，而是你要对接的东西是三十二位的。

典型情况是某些工控设备、读卡器、老式采集卡、只提供 32 位 DLL 的第三方 SDK。Python 的ctypes加载 DLL 时位数必须严格一致，64 位解释器去LoadLibrary一个 32 位 DLL 会直接抛OSError: [WinError 193] %1 不是有效的 Win32 应用程序。这时候唯一的选择就是整套环境换成 32 位。

反过来，三十二位有几条硬伤得提前知道：

• 单进程可用地址空间大约 2GB，处理稍大的数据集就容易MemoryError；
• 较新的 numpy 已经不再提供 32 位 Windows 的轮子，装的时候只能退回旧版本；
• 一部分只发 64 位轮子的库（尤其涉及深度学习、图像编解码的）在 32 位下基本无解。

所以我的判断顺序是：宿主是 32 位 Windows，或者必须加载 32 位 DLL，选 X86；其余一律 X64。X64 是三十二位系统的反向不兼容——32 位 Windows 跑不了 64 位解释器，这一点没有折中方案。

还有一个容易被忽略的点：WinPython 的目录名里通常带位数标识，比如WPy64-...和WPy32-...。解压的时候两个版本别放在同一个父目录下互相覆盖，路径里也别出现空格。

2.3 目录层级：U 盘根目录、无空格、无中文

这一条看起来最像废话，但它是翻车率最高的。路径里带空格、带中文、带&、带括号，都可能在某一步炸掉，而且报错信息往往指向别处，排查起来很折磨。

具体会出问题的地方有三个：

第一个是pip的构建过程。哪怕你只是想装一个纯 Python 包，pip也会在临时目录里展开 wheel、写元数据，某些老式setup.py对带空格的路径处理不干净，会莫名其妙报error: invalid command。第二个是编译类包，路径里的中文会让部分工具链按 GBK 解码失败，抛UnicodeDecodeError。第三个是 Windows 的 260 字符路径上限，U 盘上再套两层中文目录名，pip解压时很容易超。

我固定用的结构是这样：

P:\ ├─ Dev\ │ ├─ VSCode\ # 便携版 VS Code，Code.exe 在这一层 │ │ ├─ Code.exe │ │ └─ data\ # 手动新建，便携模式的关键 │ ├─ WinPython\ # WinPython 解压目录 │ │ └─ python-3.11.x.amd64\python.exe │ └─ conf\ │ └─ pip.ini # 便携 pip 配置，见第 4 章 ├─ packages\ │ └─ wheels\ # 离线轮子仓库 └─ work\ # 代码工作区，VS Code 从这里打开

整个结构只有两层，全英文、无空格。Dev下面三块各自独立，work单独放代码，好处是以后想换掉 WinPython 版本时，只动Dev\WinPython一个目录，其余不受影响。

至于P:这个盘符是哪来的——U 盘插到不同机器上盘符是会变的，今天是E:，明天可能就是F:。解决办法在第 3 章，用subst把 U 盘根目录映射成固定盘符，所有绝对路径都基于P:写，换机器不受影响。

3. 解压落位：VS Code 便携版、WinPython 与那个叫 data 的目录

选型定完，接下来是纯体力活，但有两个动作必须在“第一次启动之前”完成，顺序错了就得推倒重来。

3.1 VS Code 便携版解压：data 目录为什么是关键

VS Code 官方提供 zip 归档包（archive 版），解压出来直接就是可执行目录，不需要安装程序。默认情况下它会把配置和扩展写到用户目录，也就是%APPDATA%\Code和%USERPROFILE%\.vscode\extensions。放在 U 盘上这么干，等于配置留在宿主机、程序留在 U 盘，换台机器就全丢。

便携模式的开关非常简单：在Code.exe同级的目录下建一个名为data的文件夹。VS Code 启动时检测到这个目录，就会把用户数据、扩展、工作区缓存全部重定向到data下面。

# 解压后、第一次启动前的正确顺序 mkdir P:\Dev\VSCode\data # 然后才双击 Code.exe

这一步的时序很关键。如果先启动了 VS Code，它会先在%APPDATA%\Code里写一份用户配置和默认扩展，之后你再补建data目录，虽然便携模式会生效，但之前那份残留还在宿主机上，换机器时那部分配置带不走。

已经踩了的话有后悔药：把%APPDATA%\Code\User\settings.json手工复制到P:\Dev\VSCode\data\user-data\User\settings.json，扩展可以从扩展面板重新装，或者直接把%USERPROFILE%\.vscode\extensions整个拷到P:\Dev\VSCode\data\extensions。

建好之后验证一下：启动 VS Code，随便改一个设置，然后去看data\user-data\User\settings.json里有没有落下来。有，说明便携模式生效了；没有，说明data目录位置放错了，大概率是被套在了resources\app之类的子目录里。

3.2 WinPython 解压与 Control Panel 的注册动作

WinPython 的解压更简单，自解压包双击选路径，或者用 7-Zip 直接把 exe 当压缩包打开拖出来。解压完成后目录长这样：

P:\Dev\WinPython\ ├─ python-3.11.x.amd64\ # 解释器本体 │ ├─ python.exe │ ├─ Lib\site-packages\ # 第三方库都在这 │ └─ Scripts\ # pip.exe、jupyter.exe 等入口 ├─ WinPython Control Panel.exe ├─ Spyder.exe └─ Jupyter Notebook.exe

WinPython Control Panel.exe有两个功能：管理包的安装卸载，以及把这份 WinPython 注册到 Windows 系统里。第二个功能在便携场景下是绝对不能点的。

点下 “Register distribution” 之后，它会往注册表里写 Python 的文件关联、往 PATH 里加路径、把.py文件绑到这份解释器上。当时看着挺方便，双击脚本就能跑，但代价是：

• 路径被写死成E:\Dev\WinPython\...，U 盘换个盘符，注册表里全成死链；
• 拔掉 U 盘之后，宿主机上留下一堆指向不存在路径的关联，用户双击.py会弹错误框；
• 在别人的机器上做这件事，等于给人家留了个尾巴。

已经点了的话，回到 Control Panel 点 “Unregister distribution” 撤销，然后确认注册表HKCU\Software\Python下没有残留。

Control Panel 的另一个用途是装包。但我一般不用它——它本质上是调pip的图形壳，参数控制不如命令行细，装失败了也看不到完整报错。直接用python -m pip更省心。

真正需要配的是路径。便携模式下不写系统 PATH，所有路径通过 VS Code 的终端环境变量注入，这样拔了 U 盘对宿主机零影响。

3.3 settings.json：把解释器路径和终端环境钉死

到这里环境已经能跑了，但 VS Code 还不知道该用哪个 Python。这一节解决的就是“右下角选了解释器、重开又变回去”的问题——答案是别靠界面点选，直接写进配置文件。

VS Code 的设置文件是 JSONC，允许写注释。打开命令面板搜 “Open User Settings (JSON)”，或者直接编辑P:\Dev\VSCode\data\user-data\User\settings.json：

{ // 指向固定盘符下的解释器，不要写 E: 这类会随机器变化的盘符 "python.defaultInterpreterPath": "P:\\Dev\\WinPython\\python-3.11.x.amd64\\python.exe", // WinPython 不是 venv，关掉自动激活，避免终端里反复弹激活失败 "python.terminal.activateEnvironment": false, // 终端环境变量：把解释器和 Scripts 顶到 PATH 最前面 "terminal.integrated.env.windows": { "PYTHONUTF8": "1", "PYTHONIOENCODING": "utf-8", "PIP_CONFIG_FILE": "P:\\Dev\\conf\\pip.ini", "PATH": "P:\\Dev\\WinPython\\python-3.11.x.amd64;P:\\Dev\\WinPython\\python-3.11.x.amd64\\Scripts;${env:PATH}" }, // 源码统一 UTF-8，避免中文注释触发 SyntaxError "files.encoding": "utf8", "files.autoGuessEncoding": false }

几个参数值得逐个说清楚：

python.defaultInterpreterPath只在工作区没有单独指定解释器时生效，优先级低于.vscode/settings.json里的同名项。所以团队协作时把它写在工作区配置里更稳，个人机器上写用户配置就够。

terminal.integrated.env.windows里的PATH是把 WinPython 的目录拼到原有 PATH 前面，${env:PATH}是 VS Code 的变量替换语法，用来引用宿主机的原始 PATH。顺序很重要——放前面才能保证python命令命中 U 盘上这份，而不是宿主机装的那个。

PIP_CONFIG_FILE指向便携配置，作用见 4.3 节，这是防止“包装到 C 盘去”的关键一条。

python.terminal.activateEnvironment设成false，是因为 WinPython 的目录结构不是标准 venv，VS Code 的自动激活会去找Scripts\activate，找不到就报一堆警告。

盘符固定靠一个启动批处理，放在 U 盘根目录：

@echo off REM 把当前批处理所在目录（也就是 U 盘根）映射成固定盘符 P: subst P: /D >nul 2>&1 subst P: "%~dp0" if errorlevel 1 ( echo 盘符 P: 被占用，请先手动执行 subst P: /D pause exit /b 1 ) REM 用固定盘符启动，settings.json 里的路径才成立 start "" "P:\Dev\VSCode\Code.exe"

subst P: /D是先把可能残留的映射删掉，>nul 2>&1把“没有这个映射”的报错吞掉，不然每次启动都弹一行红字。%~dp0是批处理自身所在目录，带结尾反斜杠，所以后面不用再加。这个映射是会话级的，重启电脑就没了，所以每次插 U 盘都得走这个批处理，别图省事直接双击Code.exe。

4. 中文与 pip 扩展库：语言包、编码、镜像源一次配完

前三章解决的是“能跑起来”，这一章解决的是“用起来顺手”。中文环境在 Windows 上是个老话题，坑主要集中在编码上；pip 的问题则集中在“装到哪儿去了”。

4.1 中文语言包：离线 vsix 的手动装法

VS Code 的简体中文界面靠一个语言包扩展实现，扩展 ID 是MS-CEINTL.vscode-language-pack-zh-hans。有网的时候在扩展面板搜 “Chinese” 点安装就行，离线机器就得走 vsix 手动装。

做法是：在能上网的机器上打开扩展市场页面，从版本列表里下载.vsix文件，拷到 U 盘的packages目录，然后用命令行装。

REM 用便携版自带的 code.cmd 装，保证装进 data\extensions 而不是宿主机 "P:\Dev\VSCode\bin\code.cmd" --install-extension "P:\packages\vscode-language-pack-zh-hans.vsix" --force REM 装完确认一下 "P:\Dev\VSCode\bin\code.cmd" --list-extensions --show-versions

--install-extension后面既可以跟扩展 ID（联网装），也可以跟 vsix 文件路径（离线装）。--force的作用是版本相同时强制覆盖，离线反复搬运的时候很管用，不加的话会提示 “already installed” 然后跳过。--list-extensions --show-versions用来核对装没装上、装的是哪个版本。

装完扩展还不会立刻变中文，得告诉 VS Code 用哪个 locale。两种办法：一是启动时加参数Code.exe --locale=zh-cn；二是改argv.json，长期用推荐后者。便携模式下这个文件在data\user-data\下面，找不到就在data目录里搜一下文件名。

{ "locale": "zh-cn" }

改完重启 VS Code，菜单栏变中文就算成功。如果还是英文，八成是改错了argv.json——宿主机%APPDATA%\Code\argv.json和便携版的不是同一个文件，改错地方等于白改。

4.2 终端中文乱码：chcp、PYTHONUTF8 与环境变量

乱码这件事得分三层看，很多人只处理了其中一层，所以改完还是乱。

第一层是控制台代码页。Windows 中文版的 cmd 默认代码页是 936（GBK），VS Code 集成终端继承了这个设置。第二层是 Python 标准流的编码，sys.stdout.encoding在代码页 936 下会返回cp936。第三层是源文件本身的编码，.py文件如果不是 UTF-8 存的，解释器按 UTF-8 读会直接SyntaxError: Non-UTF-8 code starting with ...。

一次把三层都盖住：

REM 控制台切到 UTF-8 代码页 chcp 65001 REM 开启 Python 的 UTF-8 模式（PEP 540），open() 默认编码变成 utf-8 set PYTHONUTF8=1 set PYTHONIOENCODING=utf-8 REM 验证三个关键点 python -c "import sys,locale; print(sys.stdout.encoding, locale.getpreferredencoding())"

PYTHONUTF8=1是 Python 3.7 引入的 UTF-8 模式，开启后open()不写encoding参数也默认用 UTF-8，同时文件系统编码也统一成 UTF-8。这一条能解决绝大部分“读 CSV 读出一堆问号”的问题。

PYTHONIOENCODING=utf-8专门管标准输入输出，优先级比PYTHONUTF8对标准流的影响更高。有些场景下控制台代码页改不了（比如被组策略锁了），靠这一条也能让print出来的中文正常。

代码页 65001 还有个副作用得提：老版本的 cmd 在 65001 下会出现输入法候选框位置错乱、more命令卡住之类的小毛病。现在的 Win10/Win11 基本没这问题了，如果目标机器是更老的系统，宁可不改代码页，只靠PYTHONIOENCODING兜底。

字体也得看一眼。有些等宽字体压根没有中文字形，代码页正确、编码正确，屏幕上还是一片方块。VS Code 里设terminal.integrated.fontFamily换一个带中文回退的字体就行。

4.3 pip 落盘到 U 盘：pip.ini 的位置与写法

pip 在 Windows 上找配置文件是有优先级的，从高到低大概是：环境变量PIP_CONFIG_FILE指定的路径 →%APPDATA%\pip\pip.ini→%PROGRAMDATA%\pip\pip.ini→ Python 安装目录下的pip.ini。

便携场景下这条优先级链有个大坑：如果宿主机的%APPDATA%\pip\pip.ini里写过index-url或者target，你的pip install会读到人家的配置。表现就是“我在 U 盘上装包，包跑到 C 盘某个目录去了”，或者“明明配了镜像源还是走官方源超时”。

解决办法就是在 3.3 节的terminal.integrated.env.windows里显式设PIP_CONFIG_FILE，把查找链从第一级就截断。配置内容：

[global] index-url = https://pypi.tuna.tsinghua.edu.cn/simple trusted-host = pypi.tuna.tsinghua.edu.cn timeout = 60 retries = 3 disable-pip-version-check = true no-warn-script-location = true [install] upgrade-strategy = only-if-needed

index-url换成国内镜像，离线环境里这一步能省下大量等待。trusted-host是配合 http 源用的，漏了会报 SSL 证书校验失败。timeout和retries在 U 盘这种 I/O 偏慢的介质上有意义，默认的 15 秒有时候不够，尤其装大包的时候。no-warn-script-location是关掉“脚本不在 PATH 里”的警告——便携环境本来就不往系统 PATH 写东西，这个警告每次刷一屏很烦。

upgrade-strategy设成only-if-needed是防止 pip 顺手把你预装的 numpy 升到最新版，结果和 pandas 版本对不上。WinPython 自带的包版本是配套测试过的，别轻易动。

对于完全没网的机器，还有一套离线搬运流程：

REM 在有网机器上，把依赖全部下成 wheel（-d 指定落盘目录） python -m pip download -r requirements.txt -d P:\packages\wheels --only-binary=:all: REM 在离线机器上，只从本地目录装，不走网络 python -m pip install --no-index --find-links P:\packages\wheels -r requirements.txt

--only-binary=:all:这一条特别关键，它强制 pip 只用二进制轮子，遇到没有轮子的包直接报错退出，而不是闷头去编译。在离线机器上触发源码编译，往往要等到几十分钟后才会发现缺编译器，白等一场。--no-index关掉网络索引，--find-links指向本地目录，两个配合使用才能保证真的不联网。

python -m pip这种写法比直接敲pip多几个字符，但能保证用的是当前python对应的那个 pip。U 盘环境里 PATH 上可能同时挂着宿主机的好几个 Python，直接敲pip命中的是哪个真说不准。

5. 避坑与排查：五条在 U 盘上翻车的记录

下面这五条，是我在不同机器上真真切切撞过的。每一条都按“现象 → 原因 → 解决”记，症状描述尽量还原当时看到的样子，方便对照。

5.1 解释器和路径：重开就打回原形、换台机器全线失效

现象一：右下角状态栏选好了 U 盘上的解释器，代码能跑。关掉 VS Code 再打开，状态栏又变成 “Select Interpreter”，或者自动跳回宿主机上那个 Python。终端里敲python出来的也不是 U 盘那份。

原因：界面点选的结果被写进了当时生效的用户设置里，而便携模式没生效——data目录要么没建，要么建错了位置。于是这份设置落在宿主机的%APPDATA%\Code\User\settings.json，程序本身却在 U 盘上。在那台机器上看着是好的，换台机器就读不到。

解决：先确认data目录在Code.exe同级，启动后改一个设置，看data\user-data\User\settings.json有没有生成。有，说明便携模式正常。然后把解释器路径显式写进python.defaultInterpreterPath，别依赖界面点选。团队协作的代码库再在仓库里放一份.vscode/settings.json，优先级更高，谁打开都对。

现象二：同一套 U 盘，在自己机器上是E:，插到别人机器上变成F:，VS Code 里所有 Python 相关的红色波浪线全冒出来，终端提示系统找不到指定的路径。

原因：配置里写的是绝对路径E:\Dev\WinPython\...，盘符一变全废。Windows 分配盘符是按插入顺序和已有分区来的，你控制不了。

解决：用 3.3 节那个subst批处理把 U 盘根映射成固定盘符P:，所有配置里的路径都以P:\开头。批处理启动前先subst P: /D清理残留映射，否则上次拔盘后留下的死映射还在，新映射会失败。

提示：subst的映射在 U 盘拔出后不会自动消失，会留一个指向不存在路径的盘符。养成习惯，插 U 盘先跑批处理，拔之前执行一次subst P: /D。

5.2 扩展库：装成功了却 import 不到、编译报错一大片

现象：pip install requests打了满屏的 Successfully installed，回到 Python 里import requests照样ModuleNotFoundError。用pip show requests又能看到安装信息。

原因：pip和python不是同一份。PATH 上先命中的可能是宿主机装的那个 Python 的pip.exe，包装到了宿主机的Lib\site-packages；也可能反过来，python命中的是宿主机的，而包装进了 U 盘。WinPython 的Scripts目录里还有个pip.exe，如果你手动cd进去执行过，也很容易搞混。

解决：一律用python -m pip install xxx，然后用两条命令确认一致性：

python -c "import sys; print(sys.executable)" python -m pip -V

第一条输出解释器的绝对路径，第二条输出 pip 对应的 Python 路径，两者必须是同一份。对不上就说明 PATH 顺序有问题，回到 3.3 节检查terminal.integrated.env.windows里的PATH拼接顺序，WinPython 的两个目录必须排在${env:PATH}前面。

现象：装某个包时报error: Microsoft Visual C++ 14.0 or greater is required. Get it with "Microsoft C++ Build Tools"。

原因：pip 在当前 Python 版本和位数下找不到匹配的预编译轮子，退化成下载源码包本地编译，而便携环境里当然没有装编译器。三个常见诱因：Python 版本太新（包还没发对应轮子）、用了 32 位（很多包早就不发 32 位轮子了）、pip 版本太老识别不了新的 wheel 标签。

解决：先看 pip 到底在干什么，加-v能看到它选了哪个文件：

python -m pip install 包名 -v --only-binary=:all:

--only-binary=:all:会让它在没有轮子时立刻报错而不是去编译，报错信息里会写清楚它在找哪个标签，比如cp311-cp311-win_amd64。对照标签就能判断是版本不匹配还是位数不匹配。确认是版本问题的，换 3.11 分支；确认是位数问题的，只能换 64 位环境或者找老版本包。实在要用源码编译的，那就得在宿主机上装 Build Tools，这已经偏离“便携”的目标了。

5.3 中文与收尾：终端方块字、U 盘写保护

现象：Python 脚本里print("测试")，终端出来是����或者一串问号；或者不报乱码，直接抛UnicodeEncodeError: 'gbk' codec can't encode character。

原因：控制台代码页 936 加上 Python 标准流编码跟随 locale，两个叠在一起。print一个 GBK 里没有的字符（比如 emoji 或某些生僻字）就抛编码错误；反过来，脚本本身是 UTF-8 存的、终端按 GBK 解，就显示成方块。

解决：按 4.2 节的三层一起处理。先chcp 65001，再set PYTHONUTF8=1和set PYTHONIOENCODING=utf-8，最后确认.py文件是 UTF-8 无 BOM 保存的。VS Code 右下角能看到当前文件编码，点一下可以 “Save with Encoding” 重存。

注意：UTF-8 带 BOM 的文件在 Python 里能跑，但如果这份文件还要被别的工具读，BOM 会变成内容的一部分，容易出怪问题。统一存无 BOM 更稳。

还有一条不属于报错但很致命：U 盘本身的质量。廉价 U 盘的随机写性能极差，pip install解压几千个小文件的时候能卡到你以为死机了，中途拔盘还会导致site-packages里留下半截目录，之后import报各种诡异的ImportError。要么用固态主控的 U 盘，要么把packages\wheels放在本地硬盘上，只把解释器和代码放 U 盘。出现半截目录的，去site-packages下删掉对应包名开头的目录和*.dist-info，再重装一遍。

6. 换台机器再跑一次：验证这套便携 Python 是否真的跑通

装完当场能跑不算数，真正的验收标准是：把这根 U 盘拔下来，插到另一台从来没装过 Python 的机器上，从头走一遍，能跑通。

我固定用这张表逐项过：

再补一段把上面几项串起来的自检脚本，放在work目录下，每次换机器跑一次：

# check_env.py —— 便携环境自检，任何一项不达标就打印 FAIL import sys, os, locale # 1. 解释器必须在 U 盘的固定盘符下 exe = sys.executable print("解释器:", exe) print("PASS" if exe.upper().startswith("P:\\") else "FAIL", "解释器路径") # 2. 位数要和预期一致，64 位输出 64 print("位数:", "64" if sys.maxsize > 2**32 else "32") # 3. 标准流编码必须是 utf-8，否则中文迟早出问题 enc = sys.stdout.encoding print("标准流编码:", enc) print("PASS" if enc and enc.lower() == "utf-8" else "FAIL", "终端编码") # 4. 预装科学计算库能不能直接 import for m in ("numpy", "pandas", "matplotlib"): try: __import__(m) print("PASS", m) except ImportError: print("FAIL", m, "未安装")

这段脚本故意不检查 pip 装了什么，只检查“开箱即用”的部分——换到新机器上第一件事是确认预装库还在，而不是急着装新包。sys.maxsize > 2**32是判断解释器位数的经典写法，比读环境变量可靠。sys.stdout.encoding在代码页没切对的时候会是cp936，这一项挂了说明 4.2 节的环境变量没注进去。

从那以后我每次把 U 盘插到一台新机器

本文还有配套的精品资源，点击获取