直接修改 __builtins__ 可行但危险，因其全局影响易引发隐蔽错误；推荐用 builtins 模块重绑定或 unittest.mock.patch 进行可控拦截，生产代码应避免全局替换。
直接修改 __builtins__ 字典可行但危险
Python 的内置函数（如 print、open、len）实际挂载在模块级的 __builtins__ 上——它可能是字典（在模块顶层）或模块对象（在交互式环境）。直接赋值覆盖，比如 __builtins__['print'] = my_print，确实能生效，但副作用极强：所有后续代码（包括你没意识到会调用它的第三方库）都会受影响。一旦出错，堆栈里看不到明确来源，调试成本陡增。
常见错误现象：TypeError: 'dict' object is not callable（误把整个 __builtins__ 当成可调用对象覆盖）、或某库突然报 AttributeError: 'str' object has no attribute 'read'（因为 open 被替换成返回字符串的假函数）。
- 仅在极简脚本或单次调试中临时使用，禁止用于任何长期运行或多人协作项目
- 务必在修改前备份原始函数：
original_print = __builtins__['print'] - 若在 IPython/Jupyter 中操作，
__builtins__是模块对象，需用setattr(__builtins__, 'print', my_print)，而非字典赋值
用 builtins 模块 + import 重绑定更可控
标准做法是导入 builtins 模块（Python 3），然后对它的属性赋值。这比直接动 __builtins__ 更明确，且作用域相对清晰——只要不污染全局命名空间，影响范围限于当前模块。
示例：拦截 open 实现自动编码转换
立即学习“Python免费学习笔记（深入）”；
import builtins
<p>_original_open = builtins.open</p><p>def open(*args, *<em>kwargs):
if len(args) > 1 and isinstance(args[1], str) and 'b' not in args[1]:
kwargs.setdefault('encoding', 'utf-8')
return _original_open(</em>args, **kwargs)</p><h1>必须显式替换，否则函数名只是局部变量</h1><p>builtins.open = open
- 必须用
builtins.open = open而非仅定义同名函数——否则其他模块仍调用原版 - 这种替换会影响所有后续导入的模块（因为它们都从
builtins读取），但不会影响已加载模块的已编译字节码（即已 import 的模块若内联了builtins.open引用，可能不受影响） - 若只想对当前模块生效，应改用装饰器包装具体调用点，而非全局替换
拦截 input 或 print 时要注意重入和线程安全
像 input 和 print 这类与 I/O 绑定的函数，拦截后若内部又触发自身（例如日志打印中调用了 print），极易导致无限递归。同时，在多线程环境下，多个线程共用同一替换函数，若函数内部有共享状态（如计数器、缓存），必须加锁。
- 避免在拦截函数中直接调用同名内置函数，改用保存的原始引用：
_original_print(...) - 对
print做日志增强时，建议用sys.stdout.write替代调用print，绕过拦截链 - 若需线程局部行为（如每个线程独立 mock
input），不要全局替换，改用threading.local()配合上下文管理器
测试中用 unittest.mock.patch 是更安全的选择
真正需要拦截内置函数的场景，90% 发生在单元测试里。这时绝不要手动改 builtins，而应使用 patch——它自动处理入口还原、嵌套上下文、异常恢复，且只作用于被测函数调用栈内。
from unittest.mock import patch
<p>def test_something():
with patch('builtins.print') as mock_print:
my_function() # 内部调用 print
mock_print.assert_called_with("expected output")
-
patch('builtins.print')的字符串路径写法比直接操作对象更可靠，尤其跨 Python 版本时 - 若被测代码在模块顶层就调用了
print（即 import 时就执行），需用@patch装饰器并设autouse=True，或提前 patch 目标模块的builtins - 生产代码里硬编码拦截内置函数，基本等于给自己埋监控盲区；测试才该用 patch，上线就该删掉
真正难的不是“怎么替换”，而是判断“是否真有必要替换”。多数时候，重构调用点、注入依赖、或用 contextlib.redirect_stdout 这类定向工具，比动内置函数干净得多。
