技术博客
Composer 本身不支持“直接离线 install”，composer install 在无网络时会立即报错 Could not fetch packages。真正可行的离线方案，是把依赖包的完整分发态（含源码、autoload 映射、版本锁定）打包带走，而非只拷贝 vendor/ 目录——因为 vendor/ 中的包可能缺失 composer.json、autoload.php 初始化逻辑，或依赖本地生成的 vendor/composer/autoload_*.php 文件，这些在新环境未执行 install 前根本不存在。
go 标准库的 aes 流式加密（如 ofb 模式下的 streamreader/streamwriter）仅提供机密性，不保证完整性与真实性；若不额外加入认证机制（如 gcm、nacl secretbox），攻击者可篡改密文导致解密后数据被静默破坏。
根本原因是 Windows 终端默认使用 GBK 编码，而 Composer 输出（尤其是错误提示、包描述、composer.json 注释）通常是 UTF-8。终端无法正确解码，就显示问号或方块。
ThinkPHP 的分页不是手写 SQL + limit 拼接，而是靠 paginate() 方法自动处理查询和渲染 —— 你只要给它数据源，它就生成分页对象、计算总数、切片数据、还自带 HTML 模板。
群晖的 php 命令默认指向系统旧版（如 PHP 5.6），而 WebStation 用的是另一个路径（如 /volume1/@appstore/PHP82/usr/bin/php）；更关键的是，CLI 模式下即使你在 WebStation 图形界面勾选了 curl、openssl、json 等扩展，它们也大概率没加载——因为 CLI 读的是独立的 php.ini（通常在 /etc/php/cli-php82/php.ini），不是 WebStation 那套配置。
标准库 sync.Mutex 只作用于单个进程内，多进程同时写同一个文件时完全无效。真正起作用的是系统级的 flock（Linux/macOS）或 LockFileEx（Windows），Go 通过 syscall 或封装好的第三方包调用它们。os.File.Fd() 是关键入口——必须基于打开的文件描述符加锁，不能对路径字符串操作。
默认情况下，Sublime Text 的 Find in Files（Ctrl+Shift+F / Cmd+Shift+F）会递归扫描整个项目目录，包括 node_modules、dist、.git 等明显不需要搜索的路径。这不是性能问题，而是结果污染——你搜 fetchUser，结果里混着 200 个第三方库里的同名函数，根本没法定位。
Sublime 的编辑区背景色不由设置面板控制，也不靠主题文件（.sublime-theme）管——它只认配色方案文件（.tmTheme 或 .sublime-color-scheme）里 settings 块下的 background 字段。改这里，只动编辑区底色，不影响侧边栏、标签页、语法高亮等其他部分。
直接在命令行中指定包名，就能跳过其他依赖，只更新目标包及其满足的最小版本约束。这是最常用也最安全的细粒度控制方式。
如果项目里没有 composer.lock，直接运行 composer install 会失败，提示 Composer could not find a composer.json file in /path/to/project 或更常见的是 No composer.lock file present. You must run composer install first. —— 实际上这通常是因为它先检查了 composer.lock 是否存在，而你只放了 composer.json。