技术博客
MySQL 客户端（mysql 命令行工具）默认会把执行过的 SQL 写入用户家目录下的 ~/.mysql_history 文件，但这个行为受多个条件限制：
• 只有在未设置环境变量 MYSQL_HISTFILE 为 /dev/null 或空字符串时才生效
• 若用户以 mysql -e "SELECT 1" 方式执行命令，语句不会写入历史文件
• ~/.mysql_history 是纯文本、无时间戳、无用户标识、无连接上下文，无法区分是哪个账号、连的哪台实例、何时执行的
• 文件权限若配置不当（如被其他用户可读），反而构成安全风险
MySQL 本身不发送邮件，它只是存储邮件相关数据的数据库；真正发邮件得靠应用层（比如 Python、PHP、Java）调用 SMTP 服务，而 MySQL 负责存收件人、模板、发送记录、状态等。
Python 默认对 SIGINT（Ctrl+C）会抛出 KeyboardInterrupt，但对 SIGTERM（比如 kill <pid></pid>）直接退出，不触发任何 Python 层逻辑。想“优雅退出”，必须显式注册信号处理器。
脏读只会在 READ UNCOMMITTED 隔离级别下发生。其他三个级别（READ COMMITTED、REPEATABLE READ、SERIALIZABLE）都通过不同机制阻止了脏读——不是靠“锁住所有东西”，而是靠 MVCC（多版本并发控制）或行锁/间隙锁的组合。
调用时加不加 ()，直接决定是“拿函数本身”还是“立刻执行并取返回值”。这是最常踩的坑——尤其在传参给 threading.Timer、schedule.every().do() 或回调注册场景里。
因为这只能保证「加锁」原子性，但无法保证「解锁」安全——业务出错、超时、节点宕机时，可能删掉别人持有的锁。
真实场景里，锁的持有者必须严格校验：只有自己设的值，才能自己删。
常见错误是写个 DEL key 就完事，结果 A 拿着锁超时了，B 重新加锁，A 回来一删，把 B 的锁干掉了。
跨平台代码里直接调 getpid() 在 Windows 上会链接失败（找不到符号），而硬写 GetCurrentProcessId() 在 Linux/macOS 下根本不存在。这不是“哪个更好”的问题，而是头文件、链接库、ABI 完全隔离的两套机制。
C++ 里递归没写好，main 都没机会输出错误信息，程序就 Segmentation fault 或 stack overflow 了。根本原因不是逻辑错，是调用栈压得太深——每次递归都占一份栈空间，而默认线程栈通常只有 1~8MB。
因为每次调用 new 都要走系统堆管理器（如 malloc），涉及锁竞争、元数据维护、内存碎片整理。小对象（比如几十字节的节点）反复分配释放时，开销远超实际内存使用本身。
直接调用 http.ServeFile 看似省事，但 CDN 节点必须控制 Cache-Control、支持断点续传（Range 请求），而它默认不设缓存头，也不处理 If-None-Match 或 ETag。真实浏览器反复拉同一个 JS 文件时，会绕过本地缓存重发完整请求——这不是“静态服务”，是“静态裸奔”。