将代码写入__init__.py是否为不良代码实践？重构时需尽量移出吗？

不是所有写在__init__.py里的代码都是不良实践，但大部分场景下，应该尽量避免在里面编写复杂逻辑，优先保持它的简洁性。下面分情况说明：

合理的__init__.py代码场景 #

这些情况是行业通用的常规操作，不需要移出：

• 导出子模块符号：为了简化用户的导入路径，比如在mypkg/__init__.py里写from .core import User, create_user，用户就可以直接from mypkg import User，而不用写from mypkg.core import User。配合__all__ = ['User', 'create_user']还能明确导出范围，避免模糊导入。
• 定义包级元数据：比如包的版本号__version__ = "2.1.0"、作者信息、许可证声明等，这类数据属于包的全局标识，放在__init__.py里很合适。
• 轻量初始化逻辑：比如注册简单的插件、配置全局默认参数，且这些逻辑没有副作用（不会自动启动服务、修改系统状态等）。

应该移出的__init__.py代码 #

如果你的__init__.py里有以下内容，重构时必须移走：

• 复杂业务逻辑/工具代码：比如包含大量计算、数据处理的函数，或者完整的类定义。这些代码应该放到单独的模块（比如utils.py、business.py、models.py）里，否则会让包的结构混乱，代码难以查找和维护，还会增加包导入时的执行开销。
• 有副作用的初始化代码：比如导入包时自动创建数据库连接、启动线程、修改环境变量等。这种行为会导致包一被导入就执行操作，容易引发意外问题，也不利于单元测试。
• 重复冗余代码：如果__init__.py里的代码和其他模块内容重复，统一移到对应的模块中即可。

针对你项目的重构建议 #

1. 先逐个排查有代码的__init__.py，区分哪些是合理用法，哪些是需要迁移的代码。
2. 对于合理的导出逻辑，保留但可以优化：比如用__all__明确导出符号，避免模糊的from . import *；如果导出内容过多，可考虑让用户直接导入子模块（根据项目的使用习惯调整）。
3. 复杂逻辑、业务代码全部迁移到对应的子模块：比如把工具函数移到utils.py，类移到models.py，如果需要保持原有API兼容，可在__init__.py里保留导出语句（相当于做一层转发）。
4. 有副作用的初始化代码，改成主动调用的函数：比如把自动创建连接的代码改成init_db()函数，让用户在需要时调用，而不是包导入时自动执行。
5. 保留空的__init__.py：空文件是用来标识Python包的，即使Python 3.3+支持无__init__.py的命名空间包，保留空文件也不会有问题，还能兼容旧版本或明确包结构。

内容的提问来源于stack exchange，提问作者Eli O.