在CPython，即Python的参考实现中，locals()的行为因执行范围而异，原因是优化策略。在模块级别，locals()返回全局命名空间字典本身，这是变量的权威存储，因此任何修改都立即反映在环境中。然而，在函数内部，CPython使用了一种称为“快速局部”的优化，将变量存储在固定大小的C数组中的PyObject*指针中，而不是在哈希表中使用字节码进行索引。当在函数中调用locals()时，CPython创建一个新的字典并通过复制来自这个快速局部数组的值来填充它，产生一个临时快照。因此，对这个字典的写入仅更新了临时映射，留下底层的快速局部数组不变，因此函数继续使用原始变量值。
一个开发团队正在构建一个动态调试工具，允许开发者通过远程调试器接口向正在运行的函数作用域中注入临时的工具变量。最初的实现是在断点处捕获locals()，将助手对象注入返回的字典，并期望后续行中的运行函数能够访问这些助手。
第一种方法尝试直接修改返回的字典，假设它是函数命名空间的实时引用。优点： 不需要更改函数签名，看起来语法简单。缺点： 它静默失败，因为CPython将这个字典视为快速局部数组的只读快照；更改被丢弃，实际的局部变量保持不变。
第二种策略则改为将临时状态注入globals()，使用全局命名空间作为共享公告板。优点： 该方法在整个应用程序中持久化数据，并且可以在任何地方访问，无需传递参数。缺点： 它引入了严重的线程安全隐患，使全局命名空间污染了临时调试数据，并通过将内部状态暴露给整个进程而违反了封装原则。
最后的解决方案重构了被仪器化的函数，接受一个显式的context字典参数，调试器可以通过这个参数传递可变状态。优点： 这种方法显式、线程安全，可以在CPython、PyPy和Jython中一致工作，遵循了Python的原则：显式优于隐式。缺点： 这需要修改目标函数的签名和调用位置，相比其他方法，涉及更多的初始重构。
团队采用了显式的context传递策略。这消除了对CPython特定实现细节的依赖，防止了命名空间污染，并导致了一个稳定的跨平台调试工具。
为什么locals()在列表推导式内部的行为与模块级标准for循环不同？
在Python 3中，列表推导式引入了自己的局部作用域，类似于嵌套函数，以防止循环变量泄漏到周围的命名空间。当在推导式内部调用locals()时，它返回这个临时作用域的字典，而不是封闭的函数或模块。此外，正如在常规函数中一样，如果推导式作为单独的代码对象实现，这个字典是快速局部的快照，因此对它的写入不会持久化。相反，在模块级别，locals()是globals()的别名，即活跃的模块字典。这个区分至关重要，因为开发人员常常假设推导式与其包含块共享相同的局部命名空间，从而在尝试调试或在其中注入变量时导致困惑。
你能通过sys._getframe()操作帧对象强制写回快速局部吗？风险是什么？
高级用户可以使用sys._getframe()访问当前执行帧并修改frame.f_locals，CPython将其暴露为可写映射。在某些版本中，赋值给frame.f_locals可能会触发通过内部API如PyFrame_LocalsToFast写回到快速局部数组，但这种行为是实现相关的、版本脆弱的，并不属于语言规范的一部分。风险包括如果引用计数管理不当可能导致内存损坏、不一致的行为，其中优化器忽略更新的值，因为它已经将其缓存到寄存器或数组中，以及在其他完全不使用快速局部数组架构的Python实现（如PyPy）中完全失败。依赖这种技术会引入未定义的行为，使得跨Python版本的代码难以维护。
exec()或eval()与显式局部存在时，如何影响函数中的快速局部优化？
如果函数主体包含一个引用局部命名空间的exec()或eval()调用，CPython无法保证变量只能通过优化的快速局部数组访问；执行的字符串可能动态地引入或删除变量。为了适应这一点，编译器会为该函数禁用快速局部优化，回退到在标准字典中存储所有局部变量，并在每次访问时查询。在这种“未优化”模式下，locals()返回这个实际的字典，使其成为一个实时的、可修改的视图，修改会立即持久化。这解释了为什么使用exec()的代码通常运行得更慢，以及为什么在这样的函数中locals()看起来能“正确”地工作（允许写入），而在优化函数中则没有。