答案是用STAR法则讲清一次真实重构：情境（老系统订单导出改3处、无测试）、任务（提升可扩展性与可测性）、行动（建OrderExportDataBuilder、策略模式、配置化字段、补PHPUnit测试）、结果（新增字段耗时从45分钟降至8分钟，回归bug减70%）。
面试中被问到 PHP 代码重构经验，核心是考察你是否真正在实际项目中识别过坏味道、有意识地改进代码质量，而不是只会背设计模式或理论。
如何描述一次真实的重构经历
避免泛泛而谈“我优化了性能”或“我用了 Laravel”。面试官想听的是：你发现了什么具体问题、为什么它是个问题、你怎么做、结果如何。推荐用「情境—任务—行动—结果」（STAR）逻辑组织回答：
- 情境：比如维护一个老系统，订单导出功能每次新增字段都要改 3 个地方（控制器、服务类、Excel 生成器），且测试覆盖率几乎为 0
- 任务：让导出逻辑可扩展、易测试、不重复
-
行动：提取统一的
OrderExportDataBuilder类，用策略模式支持不同格式；把字段映射配置化；补全 PHPUnit 数据提供器测试 - 结果：后续新增导出字段平均耗时从 45 分钟降到 8 分钟，回归 bug 减少 70%
高频被追问的技术细节
面试官常会深挖你提到的重构手段是否合理，例如：
- 你说“把长方法拆成小函数”，他会问：怎么命名？参数怎么传？会不会破坏封装？ → 回答要体现职责分离，比如按领域动作命名（
calculateDiscountForVIP()而非doStep3()），优先用对象传参而非大量原始参数 - 你说“引入依赖注入”，他可能问：旧代码全是 new 实例，你怎么平滑过渡？ → 可答：先加构造函数可选参数兼容旧调用，再逐步替换工厂类，最后删掉默认实例化逻辑
- 提到“类型声明”，他可能质疑：PHP 是动态语言，强类型会不会增加维护成本？ → 可强调 PHP 7+ 的 scalar type hints + strict mode 如何提前暴露错误，减少运行时隐式转换陷阱
别踩的坑：哪些“重构”其实是倒退
有些操作看似在优化，实则降低可维护性，面试中若被反问能体现你的工程判断力：
立即学习“PHP免费学习笔记（深入）”；
- 为“遵循 SOLID”硬拆类，导致一个业务流程分散在 5 个类里，每个类只有 2 行代码 → 真实场景中，**高内聚比教条式解耦更重要**
- 把所有数组换成 Collection 对象（如 Laravel Support Collection），但项目里没用 Laravel，又没引入新包 → 属于**过度设计**，不如先写好文档说明数组结构
- 重构时删掉了所有注释，认为“代码即文档” → 忽略了 PHP 生态中很多逻辑依赖上下文（如框架钩子、魔术方法调用时机），**关键副作用必须注释**
加分项：体现重构之外的工程意识
资深候选人会把重构放在更大流程里讲：
- 重构前先加监控：用 Xdebug + Blackfire 定位真正瓶颈，避免“我觉得这里慢”式的主观优化
- 用 PHPStan 或 Psalm 做静态分析，把潜在类型错误、未定义变量等变成 CI 失败项，让重构有安全边界
- 对关键路径加特性开关（Feature Flag），新旧逻辑并行跑一周，对比日志和数据库变更，确认无误再下线旧代码
