为什么项目结构设计在 Python 面试中常被问到
面试官关注的不是你能否写出“能跑”的代码，而是你是否具备工程化思维——能否让项目易维护、可扩展、方便协作。一个清晰合理的结构，直接反映你对模块职责划分、依赖管理、测试集成和部署流程的理解深度。
高频考察点：核心目录与职责划分
面试中常要求手绘或口述典型结构，并解释每个目录存在的理由。以下是最被认可的基础骨架（适用于中等规模 CLI 或 Web 服务类项目）：
- src/：所有生产代码放这里（避免顶层 import 冲突，符合 PEP 420 包发现规范）
- tests/：与 src/ 平级，用 pytest 发现测试，支持 --import-mode=importlib
- scripts/：存放运维脚本（如数据迁移、环境初始化），不参与打包
- config/：配置文件分离（local.py / prod.py / base.py），配合环境变量加载
- requirements/：分层管理依赖（base.txt、dev.txt、prod.txt），不用单个 requirements.txt
容易踩坑的设计细节
很多候选人结构看似整齐，但一追问就暴露隐患：
- 把 __init__.py 当“装饰品”乱加——导致隐式导入、循环引用或意外暴露内部模块
- 在 src/myapp/ 下又建 myapp/ 子目录（即 src/myapp/myapp/），造成冗余层级和 import 路径混乱
- 测试文件和源码混在同一个包里（如 test_xxx.py 放在模块内），pytest 可能误导入或污染 sys.path
- 用相对导入跨层级（如 from ..utils import helper），在非包上下文（如直接 python test.py）会报错
如何体现你的设计权衡能力
面试官喜欢听你讲“为什么选这个，而不是那个”。例如：
立即学习“Python免费学习笔记（深入）”；
- 问：为什么推荐 src/ 而不是把代码放项目根目录？答：“防止当前目录被意外加入 PYTHONPATH 导致命名冲突；也利于用 pyproject.toml 的 [tool.setuptools.package-dir] 精确控制打包路径。”
- 问：配置该放代码里还是外部文件？答：“敏感信息（密钥、DB URL）必须从环境变量注入；非敏感配置（日志级别、重试次数）可放 YAML + Pydantic 模型校验，兼顾可读性与类型安全。”
- 问：怎么组织大型项目的 domain 层？答：“按业务能力（Bounded Context）切分子包（如 src/order/, src/payment/），而非技术分层（models/, views/），减少跨域耦合。”
