os.open 不是打开文件的常规方式，因为它返回整数型文件描述符而非支持缓冲和上下文管理的 file 对象，仅适用于需直连系统调用的底层场景，且需手动配对 os.close() 防资源泄漏。
为什么 os.open 不是打开文件的常规方式
因为 os.open 返回的是一个整数型文件描述符（file descriptor），不是 Python 的 file 对象，它不带缓冲、不支持 .readline() 或上下文管理（with），也不能直接用在 json.load()、pickle.load() 这类函数里。它只适合需要绕过 Python I/O 层、直连系统调用的场景，比如实现自己的缓冲逻辑、配合 os.dup2() 重定向标准流，或写底层工具。
常见错误现象：TypeError: expected str, bytes or os.PathLike object, not int —— 把文件描述符直接传给 open() 或 Path.open()；或者误以为 os.open() 返回的对象能调 .close()（它不能，得用 os.close()）。
-
os.open()是对open(2)系统调用的封装，参数和行为高度依赖 Linux/macOS，Windows 支持有限（比如不支持O_CLOEXEC） - 必须手动配对
os.close()，漏掉会导致资源泄漏——Python 的垃圾回收不自动关 fd - 权限掩码（
mode参数）只在创建新文件时生效，且需用八进制字面量，比如0o644，写成644就是十进制，权限不对
os.open 的典型参数组合怎么选
最常踩坑的是标志位（flags）乱叠，导致行为反直觉。比如想“以读写方式打开已有文件”，却用了 os.O_CREAT | os.O_RDWR，结果文件不存在时被创建，存在时也打开成功——但如果你本意是“只打开，不创建”，就错了。
- 只读已存在文件：
os.O_RDONLY（别加O_CREAT） - 读写并要求文件必须存在：
os.O_RDWR（不加O_CREAT或O_TRUNC） - 覆盖写入已有文件：
os.O_WRONLY | os.O_TRUNC（O_TRUNC会清空内容，但不创建） - 原子性地创建并独占写入：
os.O_WRONLY | os.O_CREAT | os.O_EXCL（避免竞态，失败时抛OSError: [Errno 17] File exists） - 子进程继承控制：
os.O_CLOEXEC强烈建议加上，否则 fork 后子进程会意外持有该 fd
示例：安全创建临时锁文件
立即学习“Python免费学习笔记（深入）”；
import os
try:
fd = os.open("lock.tmp", os.O_WRONLY | os.O_CREAT | os.O_EXCL | os.O_CLOEXEC, 0o600)
except OSError as e:
if e.errno == 17: # EEXIST
raise RuntimeError("Lock file already exists")
raise文件描述符 vs open() 返回的 file 对象
关键区别不在“能不能用”，而在“谁负责生命周期和缓冲”。fd 是内核句柄，轻量但裸；file 对象是 Python 封装，带行缓存、编码转换、自动关闭（with 块退出时），但多一层抽象开销。
- 性能影响：纯二进制大文件顺序读写，绕过 Python 缓冲用
os.read(fd, size)可能略快；但小量随机读、文本处理、需要编码时，open()更稳 - 兼容性：Windows 上
os.read()/os.write()对终端/管道行为不一致，macOS 和 Linux 更接近 POSIX 行为 - 混用危险：用
os.open()得到 fd，再用open(f"/proc/self/fd/{fd}", "r")包装成 file 对象？可行但极不推荐——路径依赖 procfs，且可能触发双重关闭或缓冲错乱
真正需要 fd 的典型场景：调用 os.fork() 后父子进程通信、select.poll() 监听多个 fd、用 mmap.mmap() 映射文件、或对接 C 扩展（如某些数据库驱动要求传入 fd）。
容易被忽略的清理与错误边界
fd 是稀缺资源，每个进程有上限（ulimit -n 查看，默认常为 1024）。没关掉的 fd 积累多了，后续 os.open() 会直接报 OSError: [Errno 24] Too many open files，而不是等程序结束才释放。
- 绝不要依赖“函数返回就自动关 fd”——
os.open()没这个机制 - 异常路径必须显式
os.close()：用try/finally，或封装成上下文管理器（但标准库没提供，得自己写） -
os.close()本身可能失败（比如 fd 已被关过），应捕获OSError并检查e.errno == errno.EBADF，否则可能掩盖真实问题 - 调试时用
lsof -p $PID（Linux/macOS）或procexp（Windows）查 fd 泄漏，比看代码更直观
复杂点在于：fd 是进程级全局资源，跨线程、跨 fork()、甚至跨 exec() 都可能存活，一旦逻辑链变长，谁关、何时关、关几次，很容易理不清。
