字段重命名不自动触发下游影响分析，PHP无内置血缘追踪，必须人工+工具全局搜索原字段名（如SQL、ORM、DTO、前端模板），并检查rename()返回值，否则易漏改致数据丢失。
字段重命名本身不自动触发下游影响分析，PHP 没有内置血缘追踪机制；所有影响必须靠人工+工具协同确认，否则极易漏改。
rename() 覆盖文件时不会留下任何痕迹
PHP 的 rename() 是原子操作，目标路径存在同名文件就直接覆盖，不报错、不记录、不触发钩子。你以为“移动成功”，其实原始数据已永久丢失。
- 检查返回值是唯一可靠手段：
if (rename($src, $dst) === false)—— 不要只靠file_exists($dst)做前置判断，竞态条件下毫无意义 - Windows 下若目标文件被记事本打开，
rename()会失败并返回false，错误信息通常是"Permission denied" - 跨分区移动（如
/tmp→/home）在 PHP 8.1+ 中可能退化为copy()+unlink()，此时覆盖行为不变，但不再原子
数据库字段重命名需手动同步所有依赖点
执行 ALTER TABLE ... RENAME COLUMN 只改表结构，不会扫描代码里所有 SELECT oldColumnName 或 $row['oldColumnName'] 引用。
- 必须全局搜索原字段名：
Ctrl+Shift+F搜oldColumnName，重点检查 SQL 字符串、ORM 映射、DTO 属性、前端模板变量 - Laravel Eloquent 中若用了
$casts或$appends，字段名变更后需同步更新键名，否则取值为null - SQL 查询中带别名（如
SELECT oldColumnName AS name）不受影响；但若别名和原名一致，且下游代码硬编码读$row['oldColumnName']，就会出错
GraphQL 字段别名不改变解析逻辑，但会改变响应键名
客户端写 user: getUser(id: "1")，PHP 后端 resolver 仍接收 getUser 字段名，但最终响应里键是 "user" —— 这个映射由 GraphQL 执行层完成，不经过你的 resolver。
立即学习“PHP免费学习笔记（深入）”；
- 别名不会触发额外查询，也不会让 resolver 多执行一次；它只是输出结构的“贴纸”，不是路由或分发依据
- 调试时别看响应键名去反推 resolver 名称，应查
$info->fieldName（Webonyx/GraphQL-PHP 中），它始终是原始字段名 - 如果 resolver 内部做了字段名分支判断（如
if ($info->fieldName === 'user')），那是错的；正确做法是统一处理业务逻辑，交由执行层负责别名映射
多维数组键重命名必须用引用遍历，否则改不到顶层
常见错误是用 foreach 解引用逐层赋值：$node = $tree[$a][$b]，再改 $node[$oldKey] —— 这只会改副本，原始数组结构不变。
- 必须用
&$current = &$tree+ 循环中持续加&，确保每层都保持对原始数组的引用 - 路径解析要过滤空段：
array_filter(explode('/', $path), 'strlen')，否则"a//b"会导致意外跳过层级 - 函数返回
bool表示是否成功执行，不代表“一定改了数据”——仅表示路径可达且旧键存在；若目标父级不是数组，或旧键不存在，就静默失败
最危险的盲区是：你以为改了一个地方，其实有三处没搜到——SQL 字符串拼接、前端 JS 模板变量、缓存 key 构造逻辑。血缘不是图，是散落在各处的字符串。
