知识点思维导图
29 个知识节点
参考资料
Python（36） - A2 - 附录-常用命令
你已经用 node/npm 用得很熟了。这篇不教语法，只解决一个问题：在 Python 世界里，"装环境、装包、跑代码"这三件事分别敲什么命令，以及它们和
node/npm长得像、但坑在哪。把这页当速查表，忘了回来翻。
一、核心类比（先建直觉，再划边界）
Python 的命令行三件套，几乎可以和前端一一对上：
| 前端 | Python | 作用 |
|---|---|---|
node app.js |
python app.py |
跑一个脚本 |
node（进 REPL） |
python（进 REPL） |
交互式试代码 |
npm / yarn / pnpm |
pip |
包管理器 |
node_modules（每个项目独立） |
venv 虚拟环境（要手动建） |
项目依赖隔离 |
package.json 的 dependencies |
requirements.txt |
依赖清单 |
npm install |
pip install -r requirements.txt |
按清单装依赖 |
边界（哪里不一样，必须记住）：
- 依赖隔离不是默认的。 前端
npm install默认装进当前目录的node_modules，天然按项目隔离。Python 的pip install默认装到全局（或当前解释器的全局 site-packages），不建 venv 的话，所有项目共用一套包，版本互相打架。这是新手第一个大坑。 requirements.txt≠package.json。 它没有 lockfile 那套语义，就是一行一个包的纯文本，需要你手动生成、手动维护。它更像npm ls --depth=0导出来的结果，而不是package.json。- 命令名有
3的历史包袱。 很多 mac/Linux 上python还指向老的 Python 2，得用python3/pip3。下面专门讲。
二、python：跑代码 / 进 REPL
# 跑一个脚本（等价于 node app.js）
python app.py
# 进交互式 REPL（等价于直接敲 node，Ctrl+D 退出）
python
# 查看版本（确认你用的是 3.x 不是 2.x）
python --version # 输出形如 Python 3.12.1
# 把一个"模块"当脚本跑：-m（非常常用，下面单独讲）
python -m http.server 8000 # 当场起一个静态文件服务器，类似 npx serve
2.1 python 还是 python3？（新手第一个困惑）
历史原因：很多系统里 python 指向已经废弃的 Python 2，python3 才是你要的。
# 不确定时，两个都查一下，认准 3.x
python --version # 可能是 Python 2.7.x（旧），也可能没这个命令
python3 --version # 大概率是 Python 3.x（你要用的）
实用结论：
- 命令行里优先敲
python3/pip3，最稳。 - 但一旦激活了 venv（见第二节），
python就自动指向 venv 里的 3.x，这时直接用python/pip即可，不用再纠结 3。 - 这就像前端
nvm use 18之后，node自动是 18，不用每次写全版本号。
2.2 m 是什么？（前端没有完全对应物）
-m 表示"把某个已安装的模块当成脚本来运行"，省得你去找它的可执行文件在哪。
python -m venv .venv # 运行内置的 venv 模块（建虚拟环境，见下）
python -m pip install x # 用"当前这个 python"对应的 pip 装包，避免 pip 指向别的解释器
python -m http.server # 起临时 HTTP 服务器
WHY 推荐
python -m pip而不是直接pip：当机器上有多个 Python 时，pip这个命令可能指向另一个解释器，装的包"跑的时候找不到"。python -m pip强制用"我现在这个 python"配套的 pip，从根上避免错配。这是被踩烂了的坑。
三、venv：虚拟环境（本篇最该掌握的）
这是和前端差异最大、也最容易踩坑的地方，重点讲。
一句话类比： venv ≈ 给当前项目造一个独立的 node_modules，装在项目目录里，包互不污染。区别是——前端自动给你建，Python 要你手动建并"激活"。
一个重要澄清：venv 只隔离包，不隔离/不切换 Python 版本。它用的还是创建它时那个
python（同一个解释器版本，只是复制/软链过去）。想给不同项目用不同的 Python 版本，要靠pyenv之类的工具——这点和能切 node 版本的nvm不一样，别把 venv 当成 nvm。
3.1 完整流程（建 → 激活 → 装包 → 退出）
# 1. 在项目目录里创建虚拟环境，惯例命名为 .venv（生成一个 .venv 文件夹）
python3 -m venv .venv
# 2. 激活它（关键步骤！激活后 python/pip 才指向这个隔离环境）
source .venv/bin/activate # macOS / Linux
# .venv\Scripts\activate # Windows（PowerShell / cmd）
# 激活成功后，命令行提示符前面会出现 (.venv)，类似：
# (.venv) imber@mac project %
# 3. 此时再装包，就只装进这个项目，不污染全局
pip install requests
# 4. 干完活退出环境（回到全局，提示符的 (.venv) 消失）
deactivate
3.2 和前端的对照
| 前端 | Python venv |
|---|---|
node_modules（自动生成、自动隔离） |
.venv/ 目录（手动 python -m venv 建） |
| 装在项目里，无需"激活" | 必须 source .venv/bin/activate 激活才生效 |
npm install 默认就进 node_modules |
不激活时 pip install 会装到全局 |
.gitignore 忽略 node_modules |
.gitignore 同样要忽略 .venv/ |
踩坑提醒：
- 每开一个新终端窗口都要重新
activate，激活状态不跨窗口、不持久。忘了激活就装包，是新手最常见的"明明装了却 import 不到"的原因。 - 判断是否已激活：看提示符有没有
(.venv)；或敲which python，路径里带.venv就对了。 .venv千万别提交到 git，和node_modules一样属于本地产物。
四、pip：包管理（≈ npm）
激活 venv 之后，pip 的日常命令和 npm 几乎一一对应：
# 装一个包（≈ npm install lodash）
pip install requests
# 装指定版本（≈ npm install lodash@4.17.21）
pip install "requests==2.31.0"
# 升级一个已装的包（≈ npm update）
pip install --upgrade requests
# 卸载（≈ npm uninstall）
pip uninstall requests
# 列出当前环境装了哪些包（≈ npm ls --depth=0）
pip list
# 查看某个包的信息（版本、位置、依赖）
pip show requests
4.1 命令对照表
| 操作 | npm | pip |
|---|---|---|
| 装包 | npm install pkg |
pip install pkg |
| 装指定版本 | npm install pkg@1.2.3 |
pip install "pkg==1.2.3" |
| 卸载 | npm uninstall pkg |
pip uninstall pkg |
| 升级 | npm update pkg |
pip install -U pkg |
| 列出已装 | npm ls --depth=0 |
pip list |
| 按清单装 | npm install |
pip install -r requirements.txt |
| 导出清单 | （package.json 已存在） |
pip freeze > requirements.txt |
版本号写法的小差异：pip 用
==锁定精确版本（注意是两个等号，单个=报错），>=表示不低于。npm 那套^/~语义 pip 默认没有，pip 更倾向"要么不锁，要么用==锁死"。
五、requirements.txt：依赖清单的生成与使用
前端的 package.json 是你先写、npm install 再读。Python 这边反过来——通常是你先装好包，再用 pip freeze 把当前环境"快照"导出成 requirements.txt。
# 把当前环境所有已装包及精确版本导出到清单（≈ 锁定版本）
pip freeze > requirements.txt
# 别人（或你换台机器）拿到项目后，按清单一键还原依赖
pip install -r requirements.txt
requirements.txt 内容长这样，就是纯文本，一行一个：
requests==2.31.0
fastapi==0.110.0
pydantic==2.6.0
和前端的关键差异（边界）：
| 维度 | 前端 | Python |
|---|---|---|
| 清单怎么来 | 手写 / npm install 自动写入 |
多数靠 pip freeze 从环境导出 |
| 锁文件 | 有 package-lock.json（锁全量依赖树） |
requirements.txt 默认不锁子依赖树，需要工具补 |
| 区分 dev/prod | dependencies vs devDependencies |
惯例拆成 requirements.txt + requirements-dev.txt 两个文件 |
一个常见误区：
pip freeze会把所有装的包（含子依赖）一股脑导出，列表会比你直接用到的长一截。想要更干净的"只记直接依赖"，得靠下面的现代工具或手动维护。日常学习阶段，pip freeze够用了。
六、现代工具（了解即可，按需选用）
Python 打包工具这几年在演进，知道有这些就行，初学不必全上：
| 工具 | 类比 | 一句话 |
|---|---|---|
uv |
≈ pnpm（主打快） | 新一代极快的安装/虚拟环境工具，一个命令搞定建环境+装包，越来越流行 |
poetry |
≈ yarn + 配置一体化 | 用 pyproject.toml 统一管依赖、虚拟环境、发布 |
pyproject.toml |
≈ 现代版 package.json | 新标准的项目配置文件，逐步取代 requirements.txt + setup.py |
conda |
数据科学专用环境管理 | 跑 NumPy/Pandas 这类带 C 扩展的科学计算栈时常用 |
# uv 的体验（仅示意，需先安装 uv）
uv venv # 建虚拟环境，比 python -m venv 快
uv pip install requests # 装包，接口和 pip 兼容
给新手的建议：先把 python -m venv + pip 这套基本功用熟，理解了"隔离 + 装包"的本质，再看 uv/poetry 只是把这两步包装得更顺手，心智模型完全一样。
七、实战：初始化一个 FastAPI 项目
学完前面的"环境 + 装包"基本功，这里把它串成一条真实流程：从零起一个 FastAPI 服务，跑起来、看到自动文档、导出依赖。FastAPI ≈ 后端版的 Express/Koa，但自带类型校验和交互式 API 文档。
一个关键认知：FastAPI 只是"写路由和逻辑的框架"，它自己不监听端口。真正把服务跑起来、监听 HTTP 请求的是
uvicorn（一个 ASGI 服务器）。类比前端：fastapi≈ Express 的路由/中间件写法，uvicorn≈ 那个app.listen(3000)背后的 HTTP server 进程。所以要装两个包。
7.1 完整流程（建环境 → 装包 → 写代码 → 启动 → 导出）
# 1. 建项目目录并进去
mkdir my-fastapi && cd my-fastapi
# 2. 建虚拟环境 + 激活（第二节的基本功，别跳过，否则污染全局）
python3 -m venv .venv
source .venv/bin/activate # Windows: .venv\Scripts\activate
# 3. 装 fastapi 和 uvicorn（uvicorn[standard] 会多装热重载/性能相关的可选依赖）
pip install fastapi "uvicorn[standard]"
然后写一个最小的 main.py：
启动服务：
# uvicorn 启动：main:app 表示"main.py 文件里的 app 变量"
# --reload：改代码自动重启，等价于前端的 nodemon / vite dev 热更新（仅开发用，生产别开）
uvicorn main:app --reload
# 启动后默认监听 http://127.0.0.1:8000
# 想换端口/允许外部访问：uvicorn main:app --reload --host 0.0.0.0 --port 8080
启动成功后，浏览器打开这几个地址：
| 地址 | 是什么 |
|---|---|
http://127.0.0.1:8000/ |
你写的根路由，返回 {"message": "Hello FastAPI"} |
http://127.0.0.1:8000/docs |
自动生成的交互式 API 文档（Swagger UI），能直接点着测接口，FastAPI 最香的功能 |
http://127.0.0.1:8000/redoc |
另一种风格的自动文档（ReDoc） |
最后把依赖固化，方便换机器/协作还原：
# 导出当前环境依赖（第四节的基本功）
pip freeze > requirements.txt
踩坑提醒：
uvicorn main:app里的main是文件名（不带 .py）、app是代码里的变量名，两者都要对上。文件叫server.py、变量叫application，就得写uvicorn server:application。--reload只在开发用。生产环境用多进程方式跑（如uvicorn main:app --workers 4，或用 gunicorn 挂 uvicorn worker），别带--reload。- 忘了
source .venv/bin/activate就pip install，会把 fastapi 装到全局，然后uvicorn启动时报ModuleNotFoundError——90% 是没激活 venv，回去看第二节的判断方法（which python）。 - 默认没有任何鉴权。 上面这个服务是完全公开的，任何能访问到端口的人都能调。真实项目要自己加认证（如 OAuth2/JWT，FastAPI 官方有
fastapi.security支持），别把裸服务直接暴露到公网。
7.2 用 uv 更快的版本（可选）
如果装了 uv（第五节提过，≈ pnpm 主打快），上面前三步能压缩成：
uv init my-fastapi && cd my-fastapi # 初始化项目（生成 pyproject.toml）
uv add fastapi "uvicorn[standard]" # 建环境 + 装包一步到位，自动写进 pyproject.toml
uv run uvicorn main:app --reload # 用项目环境跑，无需手动 activate
心智模型和 pip 版完全一样，只是 uv 把"建 venv + 激活 + 装包 + 记录依赖"揉成了几条命令。
八、一页速查（贴墙版）
# === 环境 ===
python3 --version # 确认 Python 版本
python3 -m venv .venv # 建虚拟环境
source .venv/bin/activate # 激活（mac/Linux）；Windows: .venv\Scripts\activate
deactivate # 退出虚拟环境
which python # 确认当前 python 指向（路径带 .venv 即已激活）
# === 装包 ===
pip install requests # 装包
pip install "requests==2.31.0" # 装指定版本
pip uninstall requests # 卸载
pip list # 看已装
pip show requests # 看某包详情
# === 依赖清单 ===
pip freeze > requirements.txt # 导出清单
pip install -r requirements.txt # 按清单还原
# === 跑代码 ===
python app.py # 跑脚本
python # 进 REPL
python -m http.server 8000 # 起临时静态服务器
九、总结
- 核心类比（先建直觉，再划边界）：依赖隔离不是默认的。 前端 npm install 默认装进当前目录的 node_modules，天然按项目隔离。Python 的 pip install 默认装到全局（或当前解释器的全局 site-packages），不建 venv 的话，所有项目共用一套包，版本互相打架。这是新手第一个大坑。 -> requirements.txt ≠ package.json。 -> 命令名有 3 的历史包袱。
- python：跑代码 / 进 REPL：历史原因：很多系统里 python 指向已经废弃的 Python 2，python3 才是你要的。
- venv：虚拟环境（本篇最该掌握的）：这是和前端差异最大、也最容易踩坑的地方，重点讲。
- pip：包管理（≈ npm）：| 装指定版本 | npm install pkg@1.2.3 | pip install "pkg==1.2.3" |
- requirements.txt：依赖清单的生成与使用：前端的 package.json 是你先写、npm install 再读。
- 现代工具（了解即可，按需选用）：给新手的建议：先把 python -m venv + pip 这套基本功用熟，理解了"隔离 + 装包"的本质，再看 uv/poetry 只是把这两步包装得更顺手，心智模型完全一样。