php 模块化设计以业务边界而非技术类型划分模块，强调可复用、低耦合、高内聚；需通过接口 / 事件通信、容器注入依赖、psr- 4 自动加载，并持续测试演进。
PHP 模块化设计不是简单地把代码拆成多个文件，而是围绕可复用、可测试、低耦合、高内聚来组织代码结构。面试中常考的不是语法细节，而是你如何权衡设计成本与长期维护收益。
模块划分的核心依据：业务边界而非技术类型
很多候选人一提模块化就立刻想到“Controller/Model/View”或“Service/Repository/DTO”，但这是分层，不是模块化。真正的模块应以业务能力为单位，比如“订单中心”“用户认证”“支付网关对接”，每个模块封装完整的业务逻辑、数据访问和对外契约。
建议做法：
- 先识别系统中的独立业务域（DDD 的 bounded context 思路），例如“优惠券发放”不应散落在用户、订单、营销多个目录下，而应自成一个
coupon模块 - 模块间通信走明确接口（interface）或事件（Event），禁止跨模块直接 new 类或调用非公开方法
- 每个模块提供自己的配置、迁移、测试和文档入口，能独立启用 / 禁用（如通过 Laravel 的 Service Provider 或自定义加载器控制）
依赖管理的关键：避免硬编码 + 合理使用容器
模块化失败最常见的原因是“假解耦”——看似分了目录，但 A 模块仍 require_once B 模块的具体类路径，或在代码里写死 new PaymentAlipay()。
正确做法：
- 所有跨模块依赖通过接口注入，具体实现由容器绑定（如 Laravel 的
bind/singleton，或 PHP-DI 的注解 / 配置驱动） - 模块自身不初始化容器，只声明所需接口（如
public function __construct(PaymentGatewayInterface $gateway)） - 核心容器初始化放在框架启动阶段（如
bootstrap/app.php），模块仅负责注册自己的服务和契约
自动加载与命名空间：让模块“即插即用”
模块要能被快速集成，必须符合 PSR-4 自动加载规范，并有清晰的命名空间映射。
实操要点：
- 每个模块根目录对应一个顶级命名空间，如
app/Modules/Inventory/→AppModulesInventory - 在
composer.json中配置 autoload 的 psr-4 映射，支持模块目录动态增删 - 避免在模块内使用全局函数或静态调用（如
cache()、config()），改用接口注入依赖的服务实例
测试与演进：模块不是一锤定音
模块化是持续过程，不是上线前的“架构仪式”。面试官更关注你如何验证和迭代模块设计。
值得关注的做法：
- 每个模块带单元测试（覆盖核心用例）和集成测试（验证与其他模块协作），用 PHPUnit + Mockery 或 Prophecy 隔离外部依赖
- 定期用工具检查耦合度，如 PHPStan 分析未声明的类引用，或自定义脚本扫描跨模块的
use语句 - 当两个模块频繁修改同一组字段或逻辑时，说明边界错了，需要合并或提取公共子模块
模块化不是炫技，是让团队在需求变快、人员流动时还能稳住交付节奏。能说清一次模块拆分背后的业务判断，比写出十种工厂模式更有说服力。
