技术博客
MySQL 报错 ERROR 1146 (42S02): Table ‘db_name.table_name’ doesn’t exist 最常见的原因是大小写或拼写错误。Linux 系统下 MySQL 默认区分表名大小写（由 lower_case_table_names 系统变量控制），而 Windows 不区分。如果你在开发机（Windows）建的表叫 User，部署到 Linux 服务器时执行 SELECT * FROM user 就可能报 1146。
MySQL 主从延迟不是靠 SHOW SLAVE STATUS 里 Seconds_Behind_Master 一眼就能信的。这个值在从库 IO 线程没拉到最新 binlog、SQL 线程卡住、甚至主库时钟漂移时都会失真。更可靠的方式是用 GTID 或时间戳打点：
你启动MySQL服务时执行 sudo service mysql start，真正被拉起来的，是一个名叫 mysqld 的后台进程——这个进程及其占用的内存、线程、日志缓冲区、查询缓存、连接管理器等合在一起，就叫“MySQL实例”。它不存数据，但管着所有数据库文件的读写、权限校验、SQL解析和事务调度。你连不上数据库？大概率是这个实例没在跑，而不是某个库丢了。
直接对 error 做 err.(MyError) 很容易 panic，尤其当 err 是 nil 或底层类型不匹配时。Go 1.13 引入的 errors.As 才是安全提取错误类型的正解——它会递归检查错误链（wrapped error），且对 nil 安全。
它只检查 composer.lock 中已安装的依赖，不扫描源码或自定义代码。结果来自 Packagist 官方维护的 [Security Advisory Database](https://github.com/composer/advisories)，覆盖主流 PHP 包（如 monolog/monolog、laravel/framework），但不会报出未收录的私有包或未公开披露的 0day。
只要用户输入进了 query 字符串拼接，就大概率能被绕过。比如用单引号闭合、注释掉后面校验逻辑、或用 UNION SELECT 拖库——这些不是“高级技巧”，而是 SQL 解析器的正常行为。
很多自动化任务用 subprocess.run() 或 subprocess.Popen() 调外部命令，但没设超时或没读 stdout/stderr，一遇到交互式程序或输出量大的命令（比如 ffmpeg、rsync -v），进程就挂住不动——不是代码崩了，是卡在 I/O 缓冲区满了。
不能直接用 composer create-project 安装 laravel-admin，它不是独立项目，而是 Laravel 的扩展包。 你得先有 Laravel 应用，再通过 composer require 引入它——否则会报错 laravel-admin requires laravel/framework ^10.0（或对应版本）这类依赖冲突，根本走不下去。
创建 MySQL 数据库最常用、最基础的语法就是 CREATE DATABASE 语句，它简单直接，一行命令就能完成建库操作。
不能直接混搭做主从，尤其是 5.7 作为主库、8.0 作为从库时，大概率会报错 ER_SLAVE_INCIDENT 或复制中断在 GTID_PURGED 初始化阶段。根本原因是 8.0 默认启用 enforce_gtid_consistency=ON 且要求所有事务带 GTID，而 5.7 的部分语句（如非事务性 DML、CREATE TEMPORARY TABLE）在未显式开启 gtid_mode=ON 时无法生成合法 GTID，导致从库拒绝执行。