技术博客
MySQL 的 InnoDB 默认用行锁，但很多情况下会 silently 升级成表锁——最常见的是在 WHERE 条件中使用了非索引字段或函数。比如执行 UPDATE user SET status=1 WHERE CONCAT(name, ”) = ‘alice’，即使 name 有索引，CONCAT 也会让优化器放弃索引，触发全表扫描+全表加锁。
会，但只在特定条件下。MySQL 的行锁（如 InnoDB 的 RECORD LOCK）和表锁（如 LOCK TABLES … WRITE 或 FLUSH TABLES WITH READ LOCK）属于不同层级的锁机制，它们不共享锁管理器，因此互斥行为不是“自动协调”的，而是靠 MySQL Server 层统一仲裁——一旦某线程持有表级写锁，所有试图获取该表任何行锁的事务都会被阻塞；反之，若已有事务在该表上持有了未提交的行锁（比如正在执行 UPDATE），再执行 LOCK TABLES t1 WRITE 也会被挂起，直到行锁释放。
常见现象是：用户在 <input type="number" step="0.01"> 里输入 3.14，但 var_dump($_POST[‘price’]) 显示 int(3)。这不是 PHP 强转的问题，而是前端传过来的数据类型就是整数——浏览器在某些 locale 或 input 属性不匹配时，会自动“修正”为整数再提交。
MySQL 基础 SQL 语句就那么几类，真正日常够用的不到 20 个关键词，但新手常卡在 WHERE 条件写错、GROUP BY 和 SELECT 字段不匹配、或者忘记加 ; 导致命令不执行——这些不是语法难，是习惯和边界没理清。
直接运行 composer require swoole/swoole 不会安装 Swoole 运行时能力，它只是个空壳包，仅声明了 "ext-swoole": "^5.0" 依赖。Composer 检查失败时抛出的错误（如 ext-swoole is missing）不是因为没装这个包，而是底层 PHP 扩展根本不存在。
WHERE 条件写错位置，查不到数据是常态，不是你手误——而是逻辑没理清。很多人写 LEFT JOIN 时，把本该过滤右表的条件（比如 status_riwayat = ‘keluar’）硬塞进 ON 子句，结果发现只返回一条记录，或者 masuk 数据直接消失。这不是 bug，是 SQL 执行顺序决定的：ON 先匹配，WHERE 后过滤。
go 中 `map[key]` 操作支持隐式双值返回（值 + 是否存在的布尔标志），但该特性仅在多变量赋值语境下生效，不能直接用于 `return` 语句；这是编译器对“comma ok”表达式的语法特例处理，而非通用多值返回机制。
函数调用时，局部变量（如 int x = 42;、std::string s = “hello”;）直接在栈上分配；函数返回时，整个栈帧被弹出，这些变量**立刻失效**，无需手动干预。这种机制快、确定、无碎片，但容量有限（通常几 MB），且无法在函数外继续使用。
Go 语言中日志级别过滤本身不复杂，但若在高频调用场景（如每秒万级请求）中不做优化，容易因字符串拼接、反射、接口分配等隐式开销拖慢性能。关键不是“关掉日志”，而是让低级别日志（如 Debug）在编译期或运行期快速跳过，避免任何无谓计算。
直接对结构体变量调用 reflect.ValueOf() 得到的是不可寻址的副本，后续无法修改字段。必须传入指针才能读写字段：