标准库

Python 标准库

Python 官方手册里的 「库」 不只指 import 进来的模块：它包含内置类型与内置函数、内置异常，以及按主题组织的一大套标准库模块。

文档怎么组织

手册按 「从内到外」 排列：先写 内置函数、内置类型、内置异常，再展开各模块。你不必像读小说一样顺序通读，但官方也建议 至少先把内置函数过一遍——后面大量示例会默认你会用 len、range、open、isinstance 这类入口，跳过这一环容易「每个例子都差半拍」。

库里三层分别是什么

第一层：核心类型，语义在文档里补全
数字、list、dict 等，字面量和语法由语言定义，但很多行为细节（方法、与其他类型的协作、边界情况）集中在标准库文档里描述。可以类比：JS 里数组字面量是语法，而常用迭代、变更方法集中在 Array 相关章节。

第二层：内置函数与内置异常
不需要 import，任何 .py 里都能直接用。Python 刻意控制这一层的体积，其余能力放进模块。类比：接近「语言自带的一小撮全局」，但规模比浏览器全局小得多。

第三层：标准库模块
这是「库」的主体：有的用 C 实现并编进解释器，有的是纯 Python 随发行版提供。用 import 使用。习惯 npm 的话，可以把它理解成：随解释器安装的一批官方维护包——路径在标准库目录里，不是项目里 pip install 的第三方依赖，但第三方包同样用 import 接入，只是来源不同。

平台与「可用性」注释

文档里常见 「适用：Unix」 之类说明：表示接口在 Unix 系环境里常见，但 不保证 在你当前操作系统上一定存在或行为完全一致。手册默认：macOS 基于 Unix 内核，多数标注 Unix 的条目在 macOS 上可用。

若某条说明同时给出 最低内核版本 和 最低 libc 版本（例如 Linux 与 glibc），表示 两个条件都要满足 才符合文档承诺。写 Dockerfile、CI 镜像或部署脚本时，这和选择 Node 版本 + glibc/musl 基础镜像 是同一类「环境契约」问题：先确认运行时，再信接口语义。

浏览器与 WebAssembly

在 wasm32-emscripten（Emscripten）和 wasm32-wasi（WASI）上，Python 跑在 沙盒 里：与进程、线程、网络、信号、进程间通信相关的 API 要么不可用，要么与常规类 Unix 行为不一致；文件描述符、权限、符号链接等也会缩水。

对前端更直观的几点（与官方描述一致，便于排错）：

• 阻塞 I/O：Emscripten 不允许阻塞式 I/O；像 sleep 这类在其他平台上「阻塞线程」的行为，在浏览器里可能表现为 卡住事件循环。
• 进程与子进程：生成进程、等待进程、发信号等 API 常不可用或调用即失败；subprocess 有时能 import，但 不要期待服务器上那套语义。
• socket 等网络栈：在 Emscripten 上往往受限（例如非阻塞、需要额外代理或 WebSocket 桥接）；WASI 也受 snapshot 约束。
• 演进中的矩阵：具体能力随 Emscripten/WASI SDK、WASM 运行时（浏览器、Node、wasmtime）和 CPython 编译选项变化——和 浏览器 API 版本矩阵 同一种心智负担。

在浏览器里跑 Python 时，常见栈是 Pyodide（CPython + Emscripten）以及基于它的 PyScript：通过 JS 桥接访问 DOM，并用 XMLHttpRequest / Fetch 做 受限网络。不要默认「能 import 就能像 Linux 服务器那样用」。

怎么读更高效

• 先内置，再按需跳模块：与官方建议一致，避免一上来扎进冷门子模块。
• 目录与索引当检索入口：和用 MDN 侧边栏一样，带着关键词定位即可。
• 全栈 / 工具链场景 出现频率较高的名字包括：pathlib、json、urllib / http、asyncio、logging、argparse 等——与 UI 无关，但与脚本、网关、BFF、运维小工具高度重叠。
• 看到「可用性」就当约束条件：在脑内和「仅 Chromium」「仅 Node」「仅 Deno」这类环境分支同级对待。