oserror: no space left on device 是系统磁盘满导致的写入拒绝，并非代码逻辑问题；需用 df -h 定位满载挂载点，重点检查 /、/tmp、/var、python 安装路径及虚拟环境所在分区，并排查日志和临时文件占用。
导入失败报 oserror: no space left on device 怎么快速定位
这不是代码逻辑问题，是系统层面的磁盘写入被拒。python 的 import 过程（尤其带编译的模块如 .pyc 生成、或依赖 c 扩展的包安装）会往 __pycache__、site-packages 或临时目录写文件，一旦对应分区满，就直接炸。
别急着删东西，先确认到底是哪个挂载点满了：
- 运行
df -h，重点看/、/tmp、/var和 Python 安装路径所在分区（比如/usr或/opt） - 如果用的是虚拟环境，检查
venv目录所在磁盘，不是只看当前工作目录 - 某些容器或 CI 环境里，
/tmp是内存盘（tmpfs），默认只有几百 MB，极易占满
清理哪些临时文件最有效
盲目 rm -rf ~/.cache 可能误删 pip 缓存（下次重下所有包），得盯准真正占空间又可安全清的目录：
-
/tmp下以pip-、easy_install-、pytest-开头的临时目录，基本是安装/测试中途崩溃留下的残骸 -
~/.cache/pip/http可删，但~/.cache/pip/Cache（注意大小写）是已下载的 wheel 包，删了会重拉 - Python 项目根目录下的
__pycache__和.pytest_cache，不影响运行，导入前不会自动生成 - Docker 构建中，
RUN pip install后没跟&& rm -rf /root/.cache/pip，缓存会留在镜像层里
pip install 卡在 “Building wheel for xxx” 且磁盘报警怎么办
这是编译阶段最吃空间的地方——Cython、numpy、pandas 等包源码编译时，临时对象文件（.o）、静态库、中间产物可能瞬时占用数 GB。不是磁盘真没空间，而是编译器没地方放中间件。
- 加
--no-cache-dir参数，跳过 pip 本地缓存，减少写入压力 - 用
--find-links指向已下载好的 wheel 文件，绕过源码编译（前提是 wheel 兼容当前平台） - 设置环境变量
TEMP=/path/to/big/disk/tmp（Linux/macOS）或set TEMP=D:\big\tmp（Windows），把编译临时目录挪走 - CI 场景下，优先用
pip install --only-binary=all xxx强制二进制安装，避免任何编译
日志文件膨胀导致 /var/log 满，影响系统级导入（如 systemd service 加载 Python 模块）
某些服务（比如用 Python 写的 systemd daemon）启动时需导入模块，而 /var/log 满会导致 journal 或 syslog 写失败，进而触发内核级限制，连 import 都被拦截——错误现象和磁盘满一样，但根源在日志。
- 查
journalctl --disk-usage，看 journald 占了多少；用journalctl --vacuum-size=100M释放旧日志 - 检查
/var/log/apt/、/var/log/cloud-init.log等大日志，用logrotate配置自动轮转（别手动rm正在写的日志文件） - Python 应用自身日志若写到
/var/log，确保用了RotatingFileHandler或TimedRotatingFileHandler，并设好maxBytes - 注意：
systemctl restart某个服务时导入失败，未必是服务代码问题，先df /var/log
空间不足的导入失败，本质是“写权限被操作系统拒绝”，不是 Python 能捕获的异常。排查顺序永远是：看 df → 锁定挂载点 → 查该分区下谁在疯狂写（lsof +L1 或 du -sh * | sort -hr | head）→ 再决定清什么、挪什么、关什么。临时目录和日志这两类，最容易被当成“不重要”拖到最后才查，其实它们才是第一现场。
