if __name__ == '__main__': 不会总执行，因为它仅在模块被直接运行（如 python xxx.py 或 python -m package.module）时成立，导入时跳过；这是python区分脚本与库的核心机制，由解释器启动时设置的__name__变量值决定。
为什么 if __name__ == '__main__': 不会总执行？
它只在模块被直接运行时才成立，导入时自动跳过。这是 Python 区分“脚本”和“库”的核心机制，不是装饰、也不是语法糖，而是解释器启动时设置的 __name__ 变量值决定的。
常见错误现象：
写完一个模块，加了 if __name__ == '__main__': 但里面代码没跑——大概率你用 import 引入了它，而不是 python xxx.py 运行；反过来，如果别人导入你的模块，结果弹出测试输出或启动了 Flask，说明你漏写了这层保护。
- 直接运行：
python utils.py→__name__是'__main__' - 被导入：
import utils→__name__是'utils' -
__name__是模块级内置变量，不可赋值，也不该手动改
__name__ 在包里怎么变？
包（含 __init__.py）中每个模块的 __name__ 都带点号前缀，比如 myapp.core.helper。只有最顶层被直接执行的那个文件，__name__ 才是 '__main__'，哪怕它在子目录里。
使用场景：你想让 myapp/cli.py 支持命令行调用，又不想影响 from myapp.cli import parse_args 导入行为——那就把入口逻辑全塞进 if __name__ == '__main__': 里。
- 包内
__init__.py里写if __name__ == '__main__':是合法的，但几乎没意义：没人会python myapp/__init__.py - 子模块里写这句，不影响父模块的
__name__值 - 用
python -m myapp.cli运行时，__name__仍是'__main__'，因为解释器把它当主模块加载
容易误用的三个地方
不是所有“想只运行一次”的逻辑都适合放这里。它解决的是“是否作为主程序启动”，不是“是否初始化一次”。很多人在这踩坑。
- 把数据库连接、日志配置等放在
if __name__ == '__main__':里，结果单元测试导入模块后连不上库——这些该放模块顶层，或封装成函数按需调用 - 写成
if __name__ == 'main':（漏了前后双下划线）→ 永远不进分支，且无报错，极难排查 - 在 Jupyter 或 IPython 里运行这段代码，
__name__是'__main__'，但模块可能已被重载多次，行为不稳定
替代方案什么时候更合适？
如果你要控制的是“是否执行某段逻辑”，而不是“是否作为脚本启动”，那 if __name__ == '__main__': 就不是最优解。比如 CLI 工具、服务启动、配置加载，更适合显式封装。
性能 / 兼容性影响：无任何开销，纯解释器层面判断，Python 2.7 到 3.12 行为完全一致。
- 需要多入口？写个
main()函数，然后if __name__ == '__main__': main()——方便测试调用 - 想让模块既可导入又可 pipx 安装？把 CLI 逻辑抽到
if __name__ == '__main__':里，同时在setup.py或pyproject.toml中配console_scripts - 用
argparse解析参数？别在if块外定义parser，否则导入时就解析 sys.argv，干扰其他模块
真正容易被忽略的点：它不保证“只执行一次”，只保证“不因导入而执行”。同一进程里多次运行同一个脚本（比如 reload），if __name__ == '__main__': 还是会反复进——这不是 bug，是设计使然。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
