php中唯一合法且强制禁止方法重写的机制是使用final关键字，子类重写会触发fatal error；它必须置于访问控制符后、返回类型前（php 7.1+），不可用于接口方法，但可用于trait；适用于核心算法、模板方法中的关键步骤及框架生命周期绑定方法。
PHP里用final关键字禁止方法被重写
PHP中唯一合法、直接、且被语言强制执行的方式，就是把方法声明为final。这不是约定或文档提醒，而是解析器层面的硬性限制——子类一旦尝试重写带final的方法，会立刻报Fatal error: Cannot override final method。
常见错误现象：有人试图用private修饰父类方法来“阻止重写”，但这其实只是让子类看不见该方法，不等于禁止重写；更有人在文档里写“请勿重写”，结果被继承时悄无声息地覆盖了逻辑，出问题才反应过来。
-
final必须放在访问控制符（如public）之后、返回类型之前（PHP 7.1+）或之后（PHP 7.0及以前），例如：final public function foo() - 不能对
__construct以外的魔术方法加final（如__toString），PHP 8.0+已允许，但老版本会报错 - 如果类本身被声明为
final（final class MyClass），那它所有方法天然不可被重写，但这是“连类都不许继承”的更强约束，粒度太粗
什么时候该用final？看这三个场景
不是所有方法都适合加final，滥用会导致扩展困难；但以下三类逻辑，加了反而更安全：
- 核心算法封装，比如支付校验的
verifySignature()——业务逻辑强依赖其行为一致性，任何重写都可能绕过风控 - 模板方法模式中的钩子调用点，比如
beforeSave()被设计为可重写，但doSave()是最终落库动作，必须final - 与框架生命周期强绑定的方法，如Laravel中某些
boot()或register()实现，重写可能导致服务注册顺序错乱
注意：加final后，PHPUnit模拟（mock）该方法也会失败，除非用getMockWithoutInvokingTheOriginalConstructor或改用依赖注入替换整类。
立即学习“PHP免费学习笔记（深入）”；
final方法的兼容性和性能影响几乎为零
PHP引擎对final的处理发生在编译阶段，不参与运行时分发，所以不会带来额外开销。ZEND VM会直接跳过虚函数表查找，反而略微快一点点——但这点差异在真实项目里测不出来。
兼容性方面：final自PHP 5.0就存在，所有现代版本（包括8.x）完全支持。唯一要注意的是，如果你写的类库要支持HHVM（已基本淘汰），得确认HHVM 3.30+才完整支持final方法的继承检查。
- 接口里的方法不能加
final（语法错误） - trait中的方法可以加
final，但仅在该trait被use进类后生效；若两个trait都提供了同名final方法，会触发Fatal error: Trait method has not been applied - 匿名类无法声明
final方法（语法不允许）
别指望注释、IDE提示或静态分析代替final
很多人在方法上写@method-final或用PHPStan/PhpStorm注解标记“不可重写”，这些全都不起作用。IDE可能标黄警告，但PHP解释器照常执行；PHPStan能报错，但只在静态扫描阶段，上线后照样被重写成功。
真正起作用的只有两件事：一是语言原生的final关键字，二是你是否在设计初期就想清楚这个方法的契约边界。后者往往比语法更重要——比如一个calculateTax()方法，如果它内部调用了未声明final的getRate()，那重写getRate()依然能改变结果，final就形同虚设。
