技术博客
很多人误以为 suggest 是“可选依赖”，加了就能按需装——其实它纯属文档性质，Composer 安装时完全忽略它，连检查都懒得做。suggest 的唯一作用是 在 composer install 或 composer update 结束后，把那几行文字打印出来给开发者看，比如 “你装了这个库，但没装 monolog/monolog，建议装上以便启用日志功能”。
Composer 安装或更新时卡在 Downloading… 或报 cURL error 28: Operation timed out，基本就是默认超时太短 + 网络不稳定，不是配置错，也不是源失效——改两个参数就能过。
长事务本身不直接消耗 CPU，但会持续持有锁、阻止 MVCC 清理、拖慢 purge 线程，最终让整个实例响应变慢甚至卡死。最典型的信号是 SHOW ENGINE INNODB STATUS 中看到大量 TRX_WAITING 或 purge lag 持续上涨。
Go 的 http.Client 默认没有超时限制，一旦后端卡住或网络异常，请求会无限等待，最终拖垮整个服务。这不是 bug，而是设计选择——把控制权交还给使用者。但生产环境里，不设超时等于埋雷。
Composer 不会因为包被标记为 abandoned 就拒绝安装或报错——它只是在终端输出一行黄色警告，然后照常拉取、解压、autoload。这个标记纯属元信息，不触发任何强制行为。
这不是回滚失败，而是回滚前等锁超时了。MySQL 在执行 ROLLBACK 前，会先尝试获取事务涉及行的排他锁（尤其在可重复读隔离级别下），如果这些行正被其他长事务持有锁且迟迟不释放，当前回滚操作就会卡住，直到 innodb_lock_wait_timeout（默认 50 秒）超时，报这个错。
C++ 本身没有内置的 REST 客户端，得靠第三方库；不选对库或不处理好异步/SSL/错误，接口调用大概率卡死、崩溃或返回乱码。
能，但不是“开箱即用”。iOS 用的是 grpc-ios（基于 C core 的 Objective-C 封装），Android 用的是 grpc-java，两者都需手动接入，不支持像 REST 那样靠 Retrofit 或 URLSession 直接发请求。
因为很多人直接拿它监听公网 IP 或 0.0.0.0，却忘了内网穿透本质是「反向代理」：客户端主动连服务器，服务器再把连接转给内网服务。监听本地端口不是错，但监听位置和时机错了就卡死。
本文详解如何在 next.js app router 中为动态路由（如 `/works/[slug]`）正确返回 http 404 状态码，避免无效 slug 返回 200 + 空数据，通过 `dynamicparams` 配置实现服务端级路由守卫。