技术博客
因为 composer outdated 默认只检查已安装到 vendor/ 的包，且按当前 composer.lock 解析依赖树——它不重新解析 composer.json 的约束，而是基于锁文件“快照”比对 Packagist 上的最新可用版本。如果你刚改了 composer.json 但没运行 composer update 或 composer install，锁文件没更新，结果就滞后。
不是插件的问题，是 Chrome 本身从 v110+ 起默认禁用了本地 file:// 协议下的 XML 解析样式表（XSLT）和部分解析逻辑。你双击打开一个 test.xml，看到的是纯文本甚至报错 XML Parsing Error: not well-formed，大概率是因为文件编码没被正确识别，或者 Chrome 根本没走 XML 解析器——它只是当普通文本渲染了。
离线依赖的本质不是“完全不联网”，而是让 composer install 不依赖实时网络拉包。关键在提前把所有依赖（含递归依赖）和元数据固化下来，CI 环境只做本地还原。
因为默认走的是「全反射 + 动态类型推导」路径，每次调用都要重新检查字段类型、查找转换器、处理嵌套结构。不是编译期绑定，而是运行时逐层 dispatch。
Sublime Text 本身不原生支持 ReasonML 或 ReScript，但两者共享同一套语法定义（.re 文件），核心在于加载正确的 Syntax Definition。ReScript 官方已弃用旧的 reason-sublime 插件，现在唯一稳定可用的是社区维护的 rescript-sublime —— 它基于 Sublime 的 .sublime-syntax 格式重写，兼容 Sublime Text 4（Build 4126+）。
Go 的单例靠包级变量 + 私有构造函数“约定俗成”，但 reflect 能绕过导出性检查，直接调用未导出的构造函数或复制结构体字段。一旦有人用 reflect.New() + reflect.Value.Elem().Set() 或 reflect.ValueOf(&instance).Elem().Interface() 二次实例化，单例就失效了。
它本质是个静态站点生成器，不是运行时服务。你跑一次 bin/satis build，它就扫一遍 composer.json 里写的包，拉代码、打标签、生成一堆 packages.json 和压缩包链接——然后就结束了。没有后台进程，不监听端口，也不自动更新。
MySQL 在执行 UPDATE 或 DELETE 时，如果多张表里存着同一份数据（比如用户姓名在 orders 表和 customers 表里都重复保存），就必须同步更新/删除多处——这不仅增加 SQL 编写负担，更关键的是：每次操作都可能触发更多行锁、更多索引维护、更多磁盘 I/O。实际压测中，冗余字段每多一个，单条 UPDATE 的平均耗时可能上升 30%～200%，尤其在高并发写入场景下，容易卡住事务链。
Go 运行时检测到对 nil 指针的解引用（即用 * 操作符读/写），会立即中止当前 goroutine 并抛出 panic。这不是编译错误，而是在运行期确定的——只要那行代码被执行，就一定崩。
只要 composer.lock 文件还在，composer install 就会严格按它还原依赖，根本不需要“回滚命令”。很多人误以为要执行什么特殊操作，其实只是没意识到锁文件才是真相。