本文解析因误将动态生成的全局变量列表（含目标变量和自身）混入迭代，导致类型矛盾异常的根本原因，并提供安全、可维护的替代方案。
本文解析因误将动态生成的全局变量列表（含目标变量和自身）混入迭代，导致类型矛盾异常的根本原因，并提供安全、可维护的替代方案。
在 Python 中遇到“list indices must be integers or slices, not list”与“'int' object is not subscriptable”交替报错，表面看是类型冲突，实则暴露了一个典型的元编程陷阱：你在遍历 globals() 时，无意中将刚刚定义的 MEM_strings 变量本身也纳入了循环范围。
回顾原始代码：
MEM_strings = [False] * 71
for var_name, var_value in (list(globals().items())[29:]):
MEM_strings[var_value] = var_name # ❌ 此处 var_value 可能是 MEM_strings 本身（即一个 list）
虽然 print(f"{var_name}:{var_value}:{type(var_value)}") 显示多数 var_value 是 int，但只要 MEM_strings 出现在切片 [29:] 范围内（它几乎必然出现，因为它是循环前刚定义的），其 var_value 就是那个长度为 71 的列表——此时用它作下标自然触发 TypeError: list indices must be integers...；而当你尝试 int(var_value) 或 var_value[0] 时，又因部分值确实是 int，导致反向报错。
✅ 正确做法：显式过滤，避免自引用
不要依赖硬编码索引（如 [29:]），而是按命名规则或类型精准筛选目标变量：
# 方案一：按变量名前缀筛选（推荐，语义清晰、稳定）
MEM_strings = [None] * 71 # 初始化为 None 更明确
for name, value in globals().items():
if name.startswith("MEM_") and name != "MEM_strings" and isinstance(value, int):
if 0 <h3>? 关键改进点说明：</h3>
-
不调用
list()+ 切片：globals().items()返回动态视图，转list再切片既低效又脆弱； -
显式排除
MEM_strings自身：防止自引用引发类型混乱； -
校验
isinstance(value, int)：确保仅处理整型值，跳过函数、模块等干扰项； -
边界检查
0：避免IndexError，提升鲁棒性。
⚠️ 注意事项：
- 全局变量顺序在不同 Python 版本或执行环境中可能变化，永远不要依赖
globals()的顺序或固定偏移量； - 若变量需在模块加载时静态初始化，建议改用
__all__显式声明，或封装为配置类； - 在大型项目中，此类反射操作应谨慎使用——优先考虑数据驱动设计（如用字典或配置文件定义映射关系）。
通过精准过滤而非位置截取，你既能消除类型歧义，又能写出可读、可测、可持续维护的代码。
