ThinkPHP升级时勿改核心文件，应优先用extend目录+命名空间注册替代，或通过事件/中间件扩展；必须修改核心时需用git打带版本号的补丁并自动化校验，配合版本判断与兼容封装确保稳定性。
修改了 ThinkPHP 核心文件，升级时怎么不丢改动
直接改 thinkphp/library/think/ 下的类，升级框架时会被覆盖——这是最常见也最危险的操作。ThinkPHP 不设计成让你动核心源码的，所以“改了核心，升级就崩”不是 bug，是预期行为。
真正可行的路只有两条：用官方支持的扩展机制替代硬改，或者把改动抽成可独立管理的补丁。
- 优先用
extend/目录 +Loader::addNamespace()注册自定义类，替换掉原think命名空间下的某个类（比如想改thinkRequest，就放extend/think/Request.php，再在common.php里注册） - 如果必须改底层行为（比如修改
thinkApp的初始化逻辑），用事件监听（app_init、http_begin）或中间件拦截，而不是直接动App.php - 所有对
thinkphp/目录的修改，必须用git stash或单独打补丁（git diff > core-fix.patch），升级后再手动重放——别指望 merge 工具能自动处理这类非标准变更
composer update 后 vendor/thinkphp 被重写，我的 patch 失效了怎么办
composer update 会完全替换 vendor/topthink/thinkphp 目录，你之前打的 patch 如果没保存好，或者没验证过新版本的代码结构，基本等于白干。
关键不是“怎么打 patch”，而是“怎么让 patch 可复用”。ThinkPHP 版本跨度大时，函数签名、类继承链、甚至文件路径都可能变，一个 patch 往往只对特定 minor 版本有效。
立即学习“PHP免费学习笔记（深入）”；
- 每次改核心前，先用
git log -n 1 vendor/topthink/thinkphp记下当前 commit hash，patch 文件名带上版本号，比如fix-request-input-6.0.12.patch - patch 前用
git diff --no-index /dev/null vendor/topthink/thinkphp/library/think/Request.php | head -20确认文件头没被意外修改（比如 BOM、注释格式变化） - 升级后别急着
git apply，先git diff vendor/topthink/thinkphp/library/think/Request.php对比新旧版差异，确认你要改的那几行还存在、上下文没变
想兼容多个 ThinkPHP 版本，但核心类方法签名不一致
比如 thinkDb 在 6.0.10 加了 transaction() 第三个参数，而你写的封装类依赖它；升级到 6.0.15 后这个参数又改名了。这种细微差异不会报错，但逻辑会静默失效。
不能靠 try-catch 判断方法是否存在——ThinkPHP 的魔术方法和动态代理会让这种判断不可靠。得从调用链源头控制。
- 用
version_compare(THINK_VERSION, '6.0.12', '>=')显式判断，而不是method_exists()或is_callable() - 把版本敏感逻辑全收进一个
DbCompat类里，对外只暴露统一接口，内部按版本分叉调用不同参数组合 - 避免在配置文件里写死类名（如
'db' => 'think\Db'），改用闭包返回实例，这样可以在闭包里做版本适配
团队多人协作时，有人忘了应用 patch，测试环境一直跑不通
没人会天天盯着 vendor/ 目录有没有被还原。等 CI 报 Call to undefined method thinkRequest::filter() 才发现，说明 patch 流程已经脱离管控。
自动化不是加个 shell 脚本就行，得让“没打 patch”这件事本身变成构建失败的明确信号。
- 在
composer.json的scripts里加"post-update-cmd": "sh ./check-core-patch.sh"，脚本里用git status -s vendor/topthink/thinkphp检查是否干净 - 把 patch 内容转成单元测试断言：比如写个测试用例，反射调用
thinkRequest的某个私有方法，断言返回值符合你的补丁逻辑——这样哪怕 patch 漏了，测试也会立刻红 - 禁止直接提交
vendor/到 git，但允许提交vendor-patches/目录，并在 README 里写清 “每次composer install后必须运行./apply-patches.sh”
最麻烦的不是 patch 本身，而是 patch 的生命周期管理——从生成、标注、验证到失效预警，每一步漏掉都会让问题延迟暴露。没人愿意维护补丁，但更没人愿意半夜修线上 500 错误。
