setuptools 可编辑安装成功却缺包，检查显式映射的公共前缀

setuptools 报可编辑安装成功，import pkg 正常，显式列出的 pkgextra 却报 ModuleNotFoundError；普通 wheel 安装又能导入两者。如果两个包名共享字符串前缀，而且映射目录在物理上嵌套，应检查 editable finder 的根包筛选。

setuptools 84.0.0 有明确触发，正式 84.2.1 的 _is_nested() 仍用字符串前缀判断逻辑关系。例如项目明确声明：

[tool.setuptools]
packages = ["pkg", "pkgextra"]
package-dir = {"pkg" = "src", "pkgextra" = "src/extra"}

两处目录都有 __init__.py。pkgextra 与 pkg 共享前缀，却不是 dotted 子包 pkg.extra；物理路径碰巧也能拼起来时，第二个显式根包可能被错误省略。

先区分发行包遗漏与可编辑映射遗漏

在源码目录之外，用实际安装环境检查两种安装形态。普通 wheel 中两个包都存在，而默认 editable 缺其中一个，才符合这条根筛选路径。若 wheel 也缺包，应继续检查包选择和目录映射；如果构建直接报多个顶层包，那是更早的自动发现阶段。

查看实际 build-system 和锁定的后端版本。editable 由选定后端生成，不是 pip 或 uv 仅因显示“安装成功”就保证所有 import 名称正确。更换前端但仍调用同一个后端，未必改变结果。

需要稳定使用时，先采用普通安装

短期可以在受控环境使用项目的正常 wheel 安装流程。它绕过当前 editable finder 的错误筛选，但源码修改不会再自动反映到已安装包，需要重新构建和安装。开发脚本和测试入口应明确接受这个区别。

不要只向 PYTHONPATH 添加整个 src，或在测试里修改 sys.path，让导入碰巧成功。这可能引入未声明的模块，还会掩盖用户实际安装发行物后的缺包。

确实需要 editable 时，可以评估让独立根包使用彼此不嵌套的标准目录映射，例如 pkg 对应 src/pkg、pkgextra 对应 src/pkgextra。这要求实际移动源码并同步配置、测试与资源路径；单改 TOML 不会把文件移过去。包的公开 import 名称应按兼容要求保留，不能为了避开前缀就随意改名。

将 pkgextra 改写成 pkg.extra 会改变导入接口，不能作为同义修正。删除显式映射、改成无约束自动发现也可能把无关目录收入发行物，应先核对真实包设计。

验收从源码树之外分别检查两个根包、必要子包和资源；普通 wheel 与 editable 还应比较导入目标。保留原布局和配置，回退时一起恢复。后续正式版本修正根筛选后，再用同一“公共前缀加物理嵌套”的用例验证，不能只用两个普通并列包通过就撤掉兼容处理。