[ LATEST LOG ]
PAGE 3 / 5
第一次遇到 LocalJumpError: unexpected return 的时候，代码看起来毫无问题：一个方法里创建了 Proc，存进实例变量，稍后再调用。可只要这个 Proc 里写了 return，调用时就会炸。把 proc 改成 lambda，一切又恢复正常。
这不是玄学，而是 Ruby 里 block、proc、lambda 三者在「参数检查」和「控制流」上的语义差异。搞清楚这几点，很多看似奇怪的行为都能解释。
Ruby 里只有 block 是语法结构，不是对象。它只能跟在方法调用后面，通过 yield 执行：
std::string_view 是 C++17 里最受欢迎的新特性之一：它只是一个“指向字符序列的指针 + 长度”，拷贝它不分配内存，传参不产生 std::string 临时对象。但很多人把它当成“轻量版 std::string”来用，于是写出了一批看似正常、实则读取已释放内存的代码。
这篇文章不讲 API 列表，只讲四个真实项目里高频出现的坑，以及一条能落地的使用规则。
1#include <iostream>先说结论：在 C++ 里，两个不同编译单元中的全局对象，谁先构造、谁后构造，标准没有规定。你的代码只要依赖了这个顺序，就等于把正确性交给链接器的心情。
这类问题有个名字，叫 static initialization order fiasco。它讨厌的地方在于：代码能编译、能链接，在开发机上跑一百次都正常，换个链接顺序或者加一个源文件，上线当天才崩。
假设我们有一个全局配置对象。
一次线上问题：订单支付成功后，异步任务负责发通知、写积分、更新报表。上线第二天，有用户反馈没收到通知，但日志干干净净，监控也没报错，任务看起来“成功”了。
最后定位到一行代码：CompletableFuture 里的异常，没有人接。
先看最小复现：
先看一段很多人第一次写移动语义时都会遇到的代码：
1#include <iostream>
2#include <string>
3#include <utility>
4
5int main() {同事发来一条查询：“我只是想给订单补上商品信息，为什么结果从 3 行变成了 4 行？”LEFT JOIN 看起来像是“左表不动，右表挂上去”，但数据库并不这么理解。它真正保证的是：左表的每一行至少出现一次；至于最终出现几次，取决于右表能匹配到几行。
下面用一组可以实际运行的 PostgreSQL 示例，把这个问题拆开。
建两张表：订单和订单明细。
很多人第一次配置线程池，是照着某篇博客写下 new ThreadPoolExecutor(10, 20, 60, TimeUnit.SECONDS, new LinkedBlockingQueue<>())。上线后一切正常，直到流量翻倍：接口 P99 从 80ms 涨到 3 秒，堆内存一路爬升，Full GC 之后也回不到原来的水位。
线程池只有七个构造参数，但它们彼此耦合。下面从“线程池到底什么时候创建线程”讲起，再说三个最常见的坑。
ThreadPoolExecutor.execute() 的判断顺序是固定的，记住这四步，后面所有问题都能推出来：
切片是 Go 里用得最多的数据结构，也是最容易被“用错但不报错”的一个。append 不报错、s[1:3] 不报错、函数传参也不报错，可程序的行为和内存占用却可能和你以为的完全不同。这篇把三个最容易踩的点拆开讲：切片到底是什么、扩容怎么发生、底层数组什么时候会被无意共享。
切片不是“数组的引用”这么模糊的东西，它在运行时就是一个三字段结构：
1type slice struct {Rust 的所有权规则在编译期解决大部分问题：一个值只有一个所有者，借用要么多个不可变，要么一个可变。但只要写稍微复杂一点的数据结构——树、图、双向链表、观察者列表——就会撞上同一个问题：我需要多个地方共享同一份数据，而且还要修改它。
标准库给出的答案是 Rc<T> 加 RefCell<T>。这个组合确实能用，但它把编译期的检查搬到了运行时，代价是 panic、引用计数开销，以及一种 Rust 里罕见的 bug：内存泄漏。这篇文章从一个真实场景出发，把这几个坑逐个拆开。
Box<T> 是独占所有权，赋值即移动。如果两个父节点要共享同一个子节点，Box 就无能为力了。Rc<T>（Reference Counting）通过引用计数实现多所有者：每次 clone 只是把计数加一，数据本身不动。
上周排查一个数据错乱的 bug，最后定位到三行代码：
1base := []int{1, 2, 3, 4}
2a := base[:2]
3b := base[1:3]