技术博客
不会自动清空，但行为取决于锁文件和依赖声明。只要 composer.lock 存在且没被删，composer update 默认只更新满足 composer.json 版本约束的包，并复用 lock 文件里记录的精确版本（除非你指定要升级某包）。真正“重装 vendor”的其实是 composer install 在没有 lock 文件时的行为——它会按 composer.json 解析最新兼容版本，结果反而更不可控。
Go 不支持 Python 那种 @decorator 语法，但你可以用「返回函数的函数」来等效实现：把目标函数传进去，返回一个带统计逻辑的新函数。这不是语法糖，而是明确的值传递——func(fn func()) func() 这类签名就是关键。
直接调用 http.ServeFile 看似省事，但 CDN 节点必须控制 Cache-Control、支持断点续传（Range 请求），而它默认不设缓存头，也不处理 If-None-Match 或 ETag。真实浏览器反复拉同一个 JS 文件时，会绕过本地缓存重发完整请求——这不是“静态服务”，是“静态裸奔”。
电子发票系统导出的XML文件，常见问题不是格式本身错误，而是编码声明与实际字节流不一致。比如文件头写着 <?xml version="1.0" encoding="UTF-8"?>，但实际内容是 GBK 编码保存的，用浏览器或文本编辑器直接打开就会解析失败。
很多人以为只要在 XML 里写上 schemaLocation，解析器就会自动联网下载或按路径读取 XSD 来校验——这是错的。schemaLocation 只是一个提示（hint），它本身不触发任何加载行为。是否使用、如何使用，完全取决于你用的解析器和它的配置方式。
不是插件的问题，是 Chrome 本身从 v110+ 起默认禁用了本地 file:// 协议下的 XML 解析样式表（XSLT）和部分解析逻辑。你双击打开一个 test.xml，看到的是纯文本甚至报错 XML Parsing Error: not well-formed，大概率是因为文件编码没被正确识别，或者 Chrome 根本没走 XML 解析器——它只是当普通文本渲染了。
它本质是个静态站点生成器，不是运行时服务。你跑一次 bin/satis build，它就扫一遍 composer.json 里写的包，拉代码、打标签、生成一堆 packages.json 和压缩包链接——然后就结束了。没有后台进程，不监听端口，也不自动更新。
Go 运行时检测到对 nil 指针的解引用（即用 * 操作符读/写），会立即中止当前 goroutine 并抛出 panic。这不是编译错误，而是在运行期确定的——只要那行代码被执行，就一定崩。
本质是默认源走国外服务器，DNS 解析慢、TCP 连接超时或中间链路丢包都会让 composer install 卡住甚至失败，不是你本地环境有问题。
在 docker 环境中部署元数据代理（如 ec2 iam 凭据代理）时，若代理自身也运行于容器内，默认网络模式会导致原始请求的源 ip 被替换为 `docker0` 网桥地址；使用 `–net=host` 可让代理直接复用宿主机网络栈，从而准确识别调用容器的真实 ip。