授权与合规声明本文全部操作对象均为自建隔离靶场本机容器或隔离虚拟机涉及安全测试的环节必须以取得合法授权为前提。未经授权的渗透测试违反《中华人民共和国网络安全法》与《刑法》相关条款须承担相应法律责任。本文只讲环境配置、版本对照与靶场隔离不含任何攻击步骤、利用载荷与绕过手法请勿将文中环境指向任何非自有系统。一、装了却用不上先把问题拆成两条路1.1 一个几乎人人都会撞上的场景在靶场里装一个 Web 工具的 Python 依赖或者在虚拟机里跑一个示例项目几乎每个人都撞过同一堵墙pip install那一步回显得干干净净看起来装好了可脚本一运行import 那一步却提示找不到这个模块。更让人晕的是它「时好时坏」同一台机器上换一个终端窗口再敲一次可能就通了在编辑器里点运行又失败开了虚拟环境之后有的包 import 得到、有的 import 不到。于是很多人把它归成「环境玄学」重装一遍 Python 了事——装完往往还是老样子。更棘手的是这类问题常常在「本机没事、换台机器又复现」之间来回让人误以为配置本身不稳定其实不稳定的不是配置而是每一次「装」与「跑」落到的解释器未必是同一个。这里先放下一个直觉这不是「包坏了」也不是「网络没下全」。多数情况下包确实装成功了出问题的不是「装」这个动作而是「装到了哪里」与「从哪里去找」这两个地址没有对上。1.2 两条路装的时候用的是哪个 pip跑的时候用的是哪个解释器把这件事拆开其实是两条独立的路径第一条装的时候用的是哪个 pip。你敲的那条安装命令最终由某一个解释器执行它会把包装进那个解释器对应的目录里。第二条跑的时候用的是哪个解释器。你运行脚本时最终由某一个解释器去加载模块它只会去自己那一份目录里找。两条路径指向同一个解释器时一切正常指向两个不同的解释器时就出现了那句「明明装了却 import 不到」。这就是本文要一路追下去的主线。先看一张分类表。你看到的现场更可能出问题的那条路先查什么安装回显成功运行时报找不到模块两条路指向了两个解释器先看「跑」的是哪个解释器换一个终端就好了「装」这一步用的 pip 变了看安装时敲的是哪个 pip有的功能正常、有的包找不到两个解释器各有各的 site-packages分别看两边的目录命令本身提示不认识这个子命令命令用错了这一类才真是语法问题1.3 本文要回答的三个问题后面六章围绕三个问题展开包被装到了哪个目录、跑的时候是哪个解释器在找、怎么用几条命令把这两件事看清楚。第 2、3 章先把「环境挂在解释器上」这条定性立住并造出一个可以复现的现场第 4、5 章给出定位动作和「为什么搬走就坏」的官方理由第 6、7 章用对照表和清单收口。本章可以带走的一句pip install成功和import成功是两件事——前者问的是「装到哪个解释器下」后者问的是「跑的是哪个解释器」把这两条路分开问题就先有了一半答案。二、环境是挂在解释器上的2.1 venv 到底是什么一句官方定义Python 官方venv模块文档在页首就把虚拟环境是什么讲清楚了逐字如下The venv module supports creating lightweight “virtual environments”, each with their own independent set of Python packages installed in their site directories. A virtual environment is created on top of an existing Python installation, known as the virtual environment’s “base” Python, and by default is isolated from the packages in the base environment, so that only those explicitly installed in the virtual environment are available.这段话里有三个要点值得单独拎出来一是每个环境有自己独立的一套软件包装在它自己的 site 目录里二是它建在一个既存的 Python 安装之上那个被依赖的安装叫这个环境的base Python三是它默认隔离于 base 环境里的包只有明确装进这个环境的包才可用。请注意第二点——「建在一个既存的安装之上」。这句就暗示了本文的主线环境不是凭空存在的它挂在某一个解释器上。2.2 判断「是否身处虚拟环境」的官方判据那么怎么知道正在跑的这个解释器是在环境里、还是在 base 里官方在「How venvs work」一节给了一条判据逐字如下When a Python interpreter is running from a virtual environment, sys.prefix and sys.exec_prefix point to the directories of the virtual environment, whereas sys.base_prefix and sys.base_exec_prefix point to those of the base Python used to create the environment. It is sufficient to check sys.prefix ! sys.base_prefix to determine if the current interpreter is running from a virtual environment.这段话给出了两对值对照关系如下表。变量在「环境内」解释器上指向在 base 解释器上指向sys.prefix/sys.exec_prefix这个虚拟环境自己的目录base 安装的目录sys.base_prefix/sys.base_exec_prefix创建它的那个 base 安装目录自己的目录官方给的判断很干净sys.prefix ! sys.base_prefix成立就说明正在跑的这个解释器站在虚拟环境里。换句话说同一个解释器身上会同时带着两个「前缀」——一个说「我是谁」一个说「我从哪来」。这两个值只要不相等就说明它站在某个环境里。这条判据是本文后半段所有定位动作的地基判断「跑的是谁」看的不是环境变量而是解释器自己报出来的这两个前缀。2.3python -m pip用的是哪个解释器清楚了「环境挂在解释器上」再回头看安装这条路径就有一个非常关键的官方句子。pip 官方文档在「Running pip」一节里逐字写道python -m pip executes pip using the Python interpreter you specified as python. So /usr/bin/python3.7 -m pip means you are executing pip for your interpreter located at /usr/bin/python3.7.这句话把「装」这条路径钉死了python -m pip里的python是谁pip 就是谁的。你写python它就用你写成python的那个解释器来跑 pip你写完整路径它就用那个路径的解释器。所以「我装的时候用的是哪个 pip」本质上等于问「我那条命令开头的python是哪一个」。pip 文档另有一句关于装到哪里的默认行为说明可以配合理解When used from within a virtual environment, common installation tools such as pip will install Python packages into a virtual environment without needing to be told to do so explicitly.也就是说当 pip 自己就跑在一个虚拟环境里时它会把包装进这个环境不需要额外指定。两句合起来是一条闭环先确定python是谁pip 就把包装到谁的环境里它装进的环境和它自己在的那个环境是同一个。所以当有人问「我装了某个包为什么没生效」时第一个该反问的其实是你那条pip命令前面写的python是哪一个本章可以带走的一句环境是挂在解释器上的——判「我在不在环境里」看sys.prefix与sys.base_prefix是否相等判「装到哪」看python -m pip里那个python是谁。三、造一个可复现的现场建一个环境看它生成了什么3.1 创建命令与它生成了什么官方给出的创建方式很直接逐字为「Virtual environments are created by executing the venv module」后接创建命令。文档同时交代了它会生成哪些东西创建目标目录需要时连父目录一起建、在里面放一个pyvenv.cfg文件其中的home键指向「执行这条命令时所用的那个 Python 安装」、建一个binWindows 上是Scripts子目录放 Python 可执行文件的副本或符号链接、再建一个lib/pythonX.Y/site-packages子目录。文档补了一句如果指定的目录本就存在会被复用。下面这条创建命令本文在 2026-10-09 于本机实测过。2026-10-09 本机实测python-mvenv venvdemo注意这里的措辞是「执行这条命令时所用的那个 Python 安装」。这句和第 2 章连起来读就得到一条很重要的推论你用什么解释器去建环境环境就挂在谁身上。pyvenv.cfg里那个home记的就是当时那个 base 安装的位置。3.2 本机实测三个值把「我是谁、我从哪来」分开环境建好之后本文让这个环境自己的解释器报一下它的身份。下面的命令在 2026-10-09 本机实测过。2026-10-09 本机实测venv/bin/python-cimport sys; print(executable, sys.executable); print(prefix, sys.prefix); print(base_prefix, sys.base_prefix)实测输出里的三个值分别指向三处位置。值实测指向它在回答什么问题sys.executable这个虚拟环境自己的bin/python绝对路径「正在跑的是哪一个可执行文件」sys.prefix这个虚拟环境自己的目录「我站在哪个环境里」sys.base_prefix创建它的那个基础解释器所在目录「我是被谁建出来的」这三个值放一起第 2 章那条判据就落到了实物上prefix和base_prefix确实不相等说明这个解释器正跑在环境里。executable指向环境自己的那个 python是本小节最该记住的一点——它说明「跑的是谁」这件事可以不用猜直接问解释器。3.3 本机实测同一条命令两个 site-packages本文最关键的证据在下面。同一条python -m pip -V在两个不同的解释器下执行指向了两个不同的 site-packages 路径。两条命令都在 2026-10-09 本机实测过。2026-10-09 本机实测venv/bin/python-mpip-Vpython-mpip-V实测结果整理成下表版本号均为截至 2026-10-09 的实测值。命令里那个pythonpip 版本pip 所在的 site-packagesvenv/bin/pythonpip 25.3虚拟环境自己的lib/python3.13/site-packages/pip宿主那个pythonpip 26.2.1宿主解释器的.../lib/python3.13/site-packages/pip这就是本文要立的核心事实命令长得一模一样只是开头那个python换了pip 就变成了另一个 pip装出来的包也就进了另一个目录。换句话说「我装的时候用的是哪个 pip」这句话答案不是一个名字而是「当时开头那个python指向哪一个解释器」。一台机器上并存两个环境、两套site-packages是再正常不过的事。这也在提示我们「这台机器上装没装某个包」这个问题本身问得不完整——还得补一句「装到了哪个解释器的site-packages里」答案才有意义。顺带记两个实测版本截至 2026-10-09本机托管 Python 为 3.13.12上表里的两个 pip 分别是 25.3 与 26.2.1。版本号会变但「同一条命令、两个路径」这个结构不会变。本章可以带走的一句用python -m venv建环境等于把环境挂在当时那个解释器上同一条python -m pip -V在两个解释器下会报出两个 site-packages 路径——这就是「包装到哪去了」的答案。四、四条定位动作先看解释器再看 site-packages4.1 激活脚本做了什么以及它为什么不是必须的先澄清一个最常见的误会很多人以为「必须激活环境才能用」。官方对激活的解释逐字如下A virtual environment may be “activated” using a script in its binary directory (bin on POSIX; Scripts on Windows). This will prepend that directory to your PATH, so that running python will invoke the environment’s Python interpreter and you can run installed scripts without having to use their full path.也就是说激活做的事情只有一件把环境的bin目录插到 PATH 的最前面这样你再敲python时找到的就是环境的那个解释器。它改的是「你敲python会落到谁身上」不是别的。也正因为如此官方紧接着说了另一句逐字为You don’t specifically need to activate a virtual environment, as you can just specify the full path to that environment’s Python interpreter when invoking Python. Furthermore, all scripts installed in the environment should be runnable without activating it.激活不是必须的。你可以直接写环境里那个解释器的完整路径来跑而且环境里装好的脚本不激活也应当能跑。这一条和第 2 章的判据严丝合缝——判「在不在环境里」看的是解释器自己的两个前缀而不是「我有没有敲过那句激活命令」。4.2 脚本里的 shebang 指向哪个解释器既然不激活也能跑那「不激活时脚本怎么知道该用哪个解释器」官方的答案逐字如下In order to achieve this, scripts installed into virtual environments have a “shebang” line which points to the environment’s Python interpreter,#!/path-to-venv/bin/python. This means that the script will run with that interpreter regardless of the value of PATH.关键在最后半句——无论 PATH 是什么脚本都会用 shebang 里那个解释器来跑。也就是说环境里安装出来的脚本第一行的 shebang 就把该用的解释器钉死了。这解释了一个现象有时候你没激活环境直接运行环境里的某个命令行工具它照样能找到同环境里装的包——因为它的 shebang 指向的就是那个环境的解释器。想亲眼确认的话可以看一眼环境里某个脚本的第一行下面的命令本文未在本机运行过。⚠️代码待验证head-n1venv/bin/某个脚本第一行应当是一条以#!开头、指向这个环境bin/python的路径。shebang 指向谁脚本就跟谁走——这是「跑的是谁」在生产环境里的另一种写法。也就是说脚本自己第一行就带了一个「该用谁」的答案你要做的只是把这个答案读出来。4.3 两个容易看错的判据第一个是环境变量VIRTUAL_ENV。官方明确提醒过它不可靠逐字为When a virtual environment has been activated, the VIRTUAL_ENV environment variable is set to the path of the environment. Since explicitly activating a virtual environment is not required to use it, VIRTUAL_ENV cannot be relied upon to determine whether a virtual environment is being used.逻辑很直白VIRTUAL_ENV是激活时才被设上的而激活本身不是必须的。既然可以「不激活直接用」那么没设VIRTUAL_ENV不代表没在用环境设了也不代表此刻跑的就是它。判环境要看解释器自己的前缀不要看这个变量。第二个是--user。pip 官方对它的说明逐字为Install to the Python user install directory for your platform. Typically ~/.local/, or %APPDATA%Python on Windows. (See the Python documentation for site.USER_BASE for full details.)也就是说带上--user时包装到的是该平台的「用户安装目录」通常写作~/.local/。它既不是某个虚拟环境的目录也不是 base 安装的目录而是第三个位置。下面这条命令本文未在本机实测过。⚠️代码待验证python-mpipinstall--user某个包注意它的安装目标仍然取决于开头那个python——因为第 2 章那条python -m pip的语义不变只是落点从「解释器自己的 site-packages」换成了「用户目录」。--user不是「绕过环境」的开关它只是换了落点至于site.USER_BASE的确切取值本文未核遇到具体平台差异请以官方site模块文档为准。三个落点放在一起对照落点由什么决定谁去这里找包环境自己的 site-packagespython -m pip里那个python是环境解释器该环境的解释器base 安装的 site-packages上面那个python是 base 解释器base 解释器用户安装目录--user命令带了--user由该解释器的用户站点配置决定细节本文未核本章可以带走的一句激活只是「把bin插到 PATH 前面」不是必须的真正决定脚本跟谁走的是 shebang而判断此刻在不在环境里只能看解释器自己的前缀不能看VIRTUAL_ENV。五、环境为什么一搬家就坏5.1 venv 的五个性质官方对虚拟环境列了五条性质逐字要点整理如下。#官方原文中文要点1“Used to contain a specific Python interpreter and software libraries and binaries which are needed to support a project…”用来承载某个特定解释器以及支撑一个项目所需的库与可执行文件2“Contained in a directory, conventionally named .venv or venv in the project directory…”装在一个目录里习惯上放在项目目录下、命名.venv或venv3“Not checked into source control systems such as Git.”不纳入 Git 这类版本控制4“Considered as disposable – it should be simple to delete and recreate it from scratch. You don’t place any project code in the environment.”被视作可弃——应当能随时删掉重建不要把项目代码放进环境里5“Not considered as movable or copyable – you just recreate the same environment in the target location.”不被视为可移动或可复制——在新位置重建而不是搬过去第 3 条和第 5 条是这一章的核心环境既不进版本控制也不该被搬来搬去。5.2 不可搬运的官方警告为什么不能搬官方给的理由和做法逐字如下Because scripts installed in environments should not expect the environment to be activated, their shebang lines contain the absolute paths to their environment’s interpreters. Because of this, environments are inherently non-portable, in the general case. You should always have a simple means of recreating an environment… If for any reason you need to move the environment to a new location, you should recreate it at the desired location and delete the one at the old location. If you move an environment because you moved a parent directory of it, you should recreate the environment in its new location. Otherwise, software installed into the environment may not work as expected.把这段话串起来因果链非常清楚因为脚本的 shebang 里写的是绝对路径这是第 4 章那条性质的直接后果所以环境天然不可携带。于是官方给的唯一正解是在新位置重建删掉旧的。如果你只是把环境的父目录整体挪了个位置也同样要「在新位置重建」。这条正好解释了那个经典现场把一个 venv 目录整个拷到另一台机器上看起来文件都在跑起来却不对劲——因为里面一堆绝对路径指向的是原来那台机器上的位置。这不是环境「坏了」而是它的设计就不支持「搬」。既然根因是绝对路径那么任何依赖「路径不变」的迁移方式都绕不开这条限制。5.3 该提交到仓库的是什么不该提交的是什么把上面五条性质收成一句可执行的纪律该进仓库的是「怎么把环境重建出来」不是环境本体。环境目录本身第 3 条不进版本控制进仓库的应当是让它能被重建出来的那点信息以及一句说明「用哪个解释器、按什么方式建」。这里只说到这里。至于「描述依赖版本的那类清单文件该怎么写、要不要锁版本」属于另一个话题本文不展开。配套资料如果你正打算把一台机器上调好的靶场环境交给别人这份环境交接清单把「该交哪几样、环境目录为什么不能直接拷」列成了一页放在资料包里扫码即可获取本章可以带走的一句环境是可弃、不可搬运、不进版本控制的要换机器或换目录正确做法是「在新位置重建、删掉旧的」而不是把目录拷贝过去。六、三类常见误解的对照表把前五章的结论换几个常见的说法复述一遍就能看出误解出在哪一步。下面三条说法在初学者里流传很广但一条都站不住。6.1 误解一报告里的路径一样就是同一个环境有人比对两边时只看了路径字符串里「看着一样」的片段就断定是同一个环境。但第 3 章的实测说明两个解释器报出来的 site-packages 可以长得几乎一样却是两个不同的目录。说法用前五章的事实回答「路径看着一样就是同一个环境」不对。两个解释器可以各有一套 site-packages看sys.prefix/base_prefix才能判「base_prefix一样就说明是同一个环境」不对。base_prefix相同只说明它们建在同一个 base 上prefix才是「我是谁」6.2 误解二激活了就一直有效激活只做了一件事——把bin插到 PATH 前面第 4 章。它有效的前提是「你这条命令确实在这个 PATH 下执行」。换个终端、换个子进程、用 shebang 指向别处的脚本都会让「激活」这件事不再覆盖到。官方也正是因此才说激活不是必须的。说法用前五章的事实回答「激活了就一劳永逸」不对。激活只是改了 PATH换个执行上下文就可能不生效「没激活就肯定没在用环境」不对。可以写解释器完整路径直接用不激活也在用「看VIRTUAL_ENV就知道」不对。官方明说它不能作为判据6.3 误解三把环境目录拷到另一台机器还能用这是第 5 章的直接应用。环境不可搬运的根因是 shebang 里的绝对路径拷贝过去之后那些路径在新机器上多半对不上。说法用前五章的事实回答「拷贝 venv 目录到新机器照样用」不对。官方把环境定义为不可搬运正确做法是在新位置重建「删掉环境会弄丢我的代码」一般不会。官方说不要把项目代码放进环境里环境是可弃的「环境要一起提交进 Git 才完整」不对。官方明说环境不纳入版本控制本章可以带走的一句三类误解都可以用同一套事实回答——判断环境看解释器的前缀、判断生效看执行上下文、判断能不能搬看 shebang 里的绝对路径。七、一张排查清单四步走7.1 四步把前六章收成一张可以照着做的清单。核心口径只有一句先看解释器再看 site-packages。步动作看什么对应事实1确认「跑的是哪个解释器」sys.executable、sys.prefix、sys.base_prefix第 2、3 章2确认「装的是哪个 pip」python -m pip -V报出的路径第 2、3 章3看两个路径是否指向同一处第 1 步的prefix与第 2 步的 site-packages 是否同源第 3 章4对不上就统一口径要么用同一个解释器重装要么直接用它的完整路径运行第 4 章第 4 步是这张清单和别的排查法不一样的地方它不要求你「重装一遍试试」而是要求你先决定「以后一直用哪一个解释器」。口径统一了「装了却 import 不到」这类问题会一次性消失一大半。真要对一遍时动作可以落成下面这几条下面这些命令本文未在本机逐条运行过按官方口径列出。⚠️代码待验证python-cimport sys; print(sys.executable, sys.prefix, sys.base_prefix)python-mpip-V这两条分别回答「跑的是谁」和「装的是谁」正好对应清单的前两步。先回答这两个问题再谈怎么修。这两条命令都不需要联网、也不改动任何文件只是把「谁在跑、装到哪」如实报出来可以放心地先跑一遍。7.2 边界交代如实交代本文的边界免得把结论用过头。第一本文只核了 Python 官方venv模块文档与 pip 官方文档这两份一手来源没有核任何操作系统发行版关于「系统 Python 是否受保护、能否直接 pip install 到系统目录」的具体策略——这一项待验证不同平台口径不同请以各自平台文档为准。第二本文只核到 pip 文档对--user的一句说明site.USER_BASE的确切取值与相关开关的行为本文未核不展开。第三本文里看脚本 shebang 的那条命令、以及本章清单里的两条命令未在本机逐一运行均保留了「代码待验证」标记第 3 章里建环境、看前缀、跑两条-V的命令是 2026-10-09 本机实测过的。7.3 收束回到开头那个场景pip install成功、import失败看着像玄学其实是两条路没对上。装的时候用的是哪个 pip跑的时候用的是哪个解释器——只要把这两个问题各自问清楚、再让它们统一这类问题就不再靠「重装一遍」来赌。环境这件事看着乱是因为它有两个入口把装与跑这两个入口都指向同一个解释器它就不乱了。配套资料本文这套「先看解释器、再看 site-packages」的四步排查清单连同三张对照表整理成了Python 环境排查卡一页放在资料包里扫码即可获取本章可以带走的一句排查只走四步——先确认跑的是哪个解释器再确认装的是哪个 pip然后看两个路径是否同源对不上就统一口径「重装一遍」不该是第一步。附表 A本文引用事实与官方出处对照表#事实陈述一手出处核验日期本文位置1PY01venv 定义逐字「The venv module supports creating lightweight “virtual environments”, each with their own independent set of Python packages installed in their site directories. A virtual environment is created on top of an existing Python installation, known as the virtual environment’s “base” Python, and by default is isolated from the packages in the base environment, so that only those explicitly installed in the virtual environment are available.」Python 官方venv模块页 — https://docs.python.org/3/library/venv.html2026-10-09第 2 章2PY02逐字「When used from within a virtual environment, common installation tools such as pip will install Python packages into a virtual environment without needing to be told to do so explicitly.」同上Python 官方venv模块页2026-10-09第 2 章3PY05判据逐字「When a Python interpreter is running from a virtual environment, sys.prefix and sys.exec_prefix point to the directories of the virtual environment, whereas sys.base_prefix and sys.base_exec_prefix point to those of the base Python used to create the environment. It is sufficient to check sys.prefix ! sys.base_prefix to determine if the current interpreter is running from a virtual environment.」同上「How venvs work」一节2026-10-09第 2、4 章4PY11逐字「python -m pip executes pip using the Python interpreter you specified as python. So /usr/bin/python3.7 -m pip means you are executing pip for your interpreter located at /usr/bin/python3.7.」pip 官方文档 User GuideRunning pip 段— https://pip.pypa.io/en/stable/user_guide/2026-10-09第 2 章5PY04创建命令「Virtual environments are created by executing the venv module:」及产物目标目录、pyvenv.cfg含home键、bin/Scripts、lib/pythonX.Y/site-packages既存目录会被复用Python 官方venv模块页2026-10-09第 3 章6PY13本机实测2026-10-09——环境内解释器报出executable 环境自己的bin/python绝对路径、prefix 环境目录、base_prefix 创建它的基础解释器目录venv/bin/python -m pip -V输出pip 25.3 from venv/lib/python3.13/site-packages/pip (python 3.13)宿主解释器下同命令输出pip 26.2.1 from .../site-packages/pip (python 3.13)本文实测2026-10-09第 2、3 章7PY14本机实测解释器版本截至 2026-10-09——托管 Python 3.13.12环境内 pip 25.3、宿主环境 pip 26.2.1本文实测2026-10-09第 3 章8PY06激活逐字「A virtual environment may be “activated” using a script in its binary directory (bin on POSIX; Scripts on Windows). This will prepend that directory to your PATH, so that running python will invoke the environment’s Python interpreter and you can run installed scripts without having to use their full path.」Python 官方venv模块页2026-10-09第 4 章9PY07逐字「You don’t specifically need to activate a virtual environment, as you can just specify the full path to that environment’s Python interpreter when invoking Python. Furthermore, all scripts installed in the environment should be runnable without activating it.」同上2026-10-09第 4 章10PY08shebang 逐字「…have a “shebang” line which points to the environment’s Python interpreter,#!/path-to-venv/bin/python. This means that the script will run with that interpreter regardless of the value of PATH.」同上2026-10-09第 4 章11PY09逐字「When a virtual environment has been activated, the VIRTUAL_ENV environment variable is set to the path of the environment. Since explicitly activating a virtual environment is not required to use it, VIRTUAL_ENV cannot be relied upon to determine whether a virtual environment is being used.」同上2026-10-09第 4 章12PY12--user逐字「Install to the Python user install directory for your platform. Typically ~/.local/, or %APPDATA%Python on Windows. (See the Python documentation for site.USER_BASE for full details.)」pip 官方文档pip install–user 段— https://pip.pypa.io/en/stable/cli/pip_install/2026-10-09第 4 章13PY03venv 五条性质逐字含「Not checked into source control systems such as Git.」「Considered as disposable…」「Not considered as movable or copyable…」Python 官方venv模块页2026-10-09第 5 章14PY10Warning 段逐字「Because scripts installed in environments should not expect the environment to be activated, their shebang lines contain the absolute paths to their environment’s interpreters. Because of this, environments are inherently non-portable, in the general case.… If for any reason you need to move the environment to a new location, you should recreate it at the desired location and delete the one at the old location.…」同上2026-10-09第 5 章15本文未核 / 待验证各操作系统发行版关于「系统 Python 是否受保护、能否直接 pip install 到系统目录」的默认策略差异——本次未核任何发行版文档表 B · NB62026-10-09第 7 章16本文未核 / 待验证site.USER_BASE的确切取值与相关开关行为——本次只核到 pip 文档对--user的一句说明表 B · NB52026-10-09第 4、7 章附表 B术语速查表术语一句话解释虚拟环境venv建在一个既存 Python 安装之上、拥有独立软件包集合与 site 目录的环境base Python创建某个虚拟环境时所依赖的那个 Python 安装sys.executable正在跑的这个可执行文件的路径回答「跑的是谁」sys.prefix/sys.exec_prefix站在环境里时指向环境目录回答「我是谁」sys.base_prefix/sys.base_exec_prefix指向创建它的 base 安装目录回答「我从哪来」site-packages解释器存放第三方包的目录环境与 base 各有一套激活activate把环境的bin目录插到 PATH 最前面非必须shebang脚本第一行以#!开头、指向某解释器的路径决定脚本跟谁走VIRTUAL_ENV激活时才设置的环境变量官方明说不能作为判断依据python -m pip用写成python的那个解释器来执行 pip--user让 pip 把包装到该平台的用户安装目录通常写作~/.local/可弃disposable环境应当能随时删除重建官方不把项目代码放进去不可搬运non-portable因 shebang 内是绝对路径环境不能靠拷贝搬迁只能在新位置重建写在最后这篇用到的资料写这篇文章时我把「环境」这个词拆成两条路来看装的时候用的是哪个 pip跑的时候用的是哪个解释器——最费劲的不是找官方原文而是把「重装一遍」这个习惯先劝退。顺手也整理了几份配套的东西Python 靶场环境排查卡解释器、pip 与 site-packages 的三张对照表加一张四步排查清单Web 安全学习路线图从基础打牢到安全管理四个阶段各学什么常用靶场清单每个靶场练什么、适合哪个阶段资料是我自己整理的放在下面这个码上扫码即可获取添加时备注「靶场」优先通过。拿到之后建议先看Python 靶场环境排查卡那一份先把「装的是谁、跑的是谁」这两个问题分开再回来看本文第 3 章那两条-V的实测会更容易对上号。