根本原因是Python 3废除隐式相对导入并强化导入校验：import b默认为绝对导入，同包模块须显式写from . import b；__init__.py从标记文件变为执行入口，其内导入失败直接触发“xxx is not a package”；sys.path[0]始终为脚本所在目录，非工作目录，需用python -m或手动补路径。
ModuleNotFoundError 和 'xxx' is not a package 这两类报错在 Python 3 下突然变多，根本不是“Python 3 更严格”，而是它把原来模糊容忍的行为显式暴露出来了——你写的导入逻辑在 Python 2 里本就不合法，只是解释器没拦你。
直接原因：绝对导入成默认，相对导入必须显式声明
Python 2 默认启用隐式相对导入。比如你在 package/a.py 里写 import b，解释器会先找同级的 b.py，找不到才去 sys.path 里找。这种行为容易遮蔽第三方模块（比如你建了个 json.py，import json 就永远导不进标准库），也导致跨目录结构一动就崩。
Python 3 彻底废除了这个机制：import b 永远是绝对导入，只认 sys.path 里的顶层模块。如果你真想导入同包下的 b.py，必须写成：
-
from . import b（导入模块） -
from .b import func（导入成员）
否则就报 ModuleNotFoundError: No module named 'b'——因为 b 根本不在 sys.path 里，也不是顶层包名。
- 隐式相对导入在 Python 3 中已完全移除，任何依赖它的代码都会立即失败
- 即使你加了
from future import absolute_import，Python 2 也只是“建议性开启”，而 Python 3 是强制执行 - 报错位置往往不在出问题的那行，而在被它间接调用的模块里（比如
a.py导入了b.py，但b.py里有隐式相对导入，错误却报在a.py的import b上）
init.py 的语义变了：从“标记文件”变成“执行入口”
Python 2 中，init.py 只要存在，目录就算包；内容为空也行。Python 3（尤其 3.3+）引入命名空间包后，空的 init.py 不再是必需项，但一旦你写了它，它就会被真正执行。
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
这意味着：
- 如果你在
init.py里写了import xxx，而xxx本身又依赖尚未初始化的兄弟模块，就可能触发'xxx' is not a package或循环导入 - Python 2 可能因延迟加载侥幸跑通，Python 3 在包加载阶段就校验完整结构，直接失败
- 更隐蔽的是：你删掉某个
init.py后，原以为只是“变普通目录”，结果整个包路径从sys.path中消失，下游所有绝对导入全挂
sys.path[0] 的行为差异：入口脚本目录 vs 工作目录
Python 2 运行 python subdir/main.py 时，sys.path[0] 是 subdir；Python 3 保持一致。但很多人误以为“只要文件在当前目录就能导”，于是：
- 在项目根目录下写
python src/main.py -
main.py里写import utils（期望导入根目录下的utils.py） - 结果失败：因为
sys.path[0]是src/，不是根目录
这个行为 Python 2 和 3 完全一样，但 Python 2 的隐式相对导入常让人误判成功——比如 main.py 里其实写的是 from .. import utils，但漏写了 ..，Python 2 碰巧在 sys.path[0] 找到了同名文件，就糊弄过去了；Python 3 拒绝这种模糊匹配，直接报错。
- 不要依赖
sys.path[0]自动包含父目录，该加的路径手动加，该重构的结构尽早重构 - 用
python -m package.main启动，能让sys.path[0]变成项目根目录，这是最干净的解法 - 运行前先确认：
python -c "import sys; print(sys.path[0])"
最麻烦的不是报错本身，而是有些代码在 Python 3 下能跑通，但靠的是未定义行为（比如模块缓存残留、init.py 执行顺序巧合）。这类“伪正常”会在你升级依赖、换环境或加测试时突然爆发，比明错更难定位。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
