PHP应用应分层清晰：View→Controller→Service→Repository，各层职责分明；接口与实现分离，依赖注入替代硬编码；合理使用缓存与异步队列；面向扩展设计，如日志、权限、认证均通过接口+策略模式支持灵活扩展。
明确分层职责，避免逻辑混杂
PHP 应用常见分层是「表现层（View）→ 控制层（Controller）→ 服务层（Service）→ 数据访问层（Repository/DAO）」。面试中强调每层只做一件事：Controller 不处理业务规则，只做参数校验、调用 Service、返回响应；Service 封装完整业务流程（如“下单”包含库存扣减、订单生成、消息通知），不直接操作数据库；Repository 负责单表增删改查，屏蔽底层驱动差异（MySQL/Redis/Elasticsearch）。遇到复杂业务时，可进一步拆出 Domain Model 和 Application Service，体现对 DDD 的理解。
接口与实现分离，支持灵活替换
用接口（Interface）定义契约，类通过依赖注入实现具体逻辑。例如定义 PaymentGatewayInterface，再提供 AlipayGateway 和 WechatPayGateway 两个实现。这样测试时可用 Mock 实现，上线后也能按配置动态切换支付渠道。面试官常关注你是否写过类似 new AlipayGateway() 这样的硬编码——应改为构造函数或方法注入，并配合容器（如 Laravel Service Container 或 Symfony DI）管理生命周期。
合理使用缓存与异步，别让请求卡在慢操作上
高频读场景（如商品详情、用户资料）优先走 Redis 缓存，设置合理过期策略和缓存穿透防护（如空值缓存 + 布隆过滤器）；写多读少或强一致性要求高的数据（如账户余额）慎用缓存，必要时用「先更新 DB，再删缓存」或「延时双删」。耗时操作（发邮件、生成报表、图片压缩）必须剥离到队列（如 Redis Queue、RabbitMQ），Controller 只负责投递任务 ID 并立即返回，前端轮询或 WebSocket 接收结果。
面向扩展而非修改，应对需求变化
新功能尽量不改旧代码。比如日志记录，不写死 file_put_contents()，而是定义 LoggerInterface，后续可无缝接入 Monolog、Sentry 或自研日志中心；权限校验不用 if-else 堆砌角色判断，改用策略模式（PermissionStrategy）或 Gate/Policy（Laravel 风格）。当被问“如果要加短信登录”，能立刻指出只需新增 SmsAuthenticator 实现统一接口，注册进认证门面即可，不影响原有账号密码逻辑。
立即学习“PHP免费学习笔记（深入）”；
