分类： 语言教程

在 Rust 里解析配置、处理网络响应、读取嵌套 JSON 时，最常见的写法是 match 里套 match，层层缩进之后，真正的业务逻辑被推到屏幕右侧。Rust 1.65 稳定了 let-else，它把「匹配成功就绑定变量、失败就立刻离开当前控制流」这段样板代码压缩成一行。但很多人把它当成语法糖直接套到嵌套 Result 上，随后撞上两类硬伤：一是 els

把一个 @dataclass 实例丢进 set 或当作 dict 的 key，很快会遇到两类问题：一是 TypeError: unhashable type，二是「明明字段值不同，却被集合判成同一条」或者反过来「以为是同一条，却出现两条」。前者来自 dataclass 默认把 __hash__ 置为 None，后者来自 eq 与 frozen 两个开关对 _

把 Option<T> 转成 Result<T, E> 时，ok_or 和 ok_or_else 是编译器提示里出现频率最高的一对方法。多数人凭直觉选：错误值简单就用 ok_or，需要格式化就用 ok_or_else。这个直觉方向没错，但理由常常说不清，于是代码里出现两种极端：一种是无脑全用 ok_or，在热路径上白白构造了一个立刻被

在 TypeScript 里处理对象类型转换时，keyof、索引访问 T[K] 和 as 子句几乎总是一起出现。看起来只是三行泛型，实际写进项目里却经常出现两种极端：要么推导结果是 never，要么 as 把键名重映射成了 string 这种宽类型，导致下游类型守卫全部失效。本文围绕这三个语法点的交互边界展开，用可运行的代码片段说明什么时候能推导、什么时候会

用 record 承载请求参数、配置项、值对象时，最容易踩的坑不是「怎么少写 getter」，而是「构造时该不该校验、怎么校验、规范化后的值怎么写回去」。很多人第一次写紧凑构造器（compact constructor）时写出了 this.name = name.trim();，编译器直接报 error: cannot assign a value to f

在 Python 的日常开发里，@dataclass 几乎是定义数据载体的默认选择。但很多人只用到「声明字段、自动生成 __init__」这一步，一旦遇到「字段需要由其他字段计算得来」的场景，就退回去手写 __init__，把 dataclass 带来的简洁性丢掉了。更常见的情况是：给派生字段写了一个 field(init=False)，然后直接赋值 fie

写 Rust 的人几乎都会卡在同一个岔路口：trait 有了，实现也有好几个，接下来是把函数签名写成 -> impl Trait，还是写成 -> Box<dyn Trait>？两者在调用方看起来差不多，都能"返回一个实现了该 trait 的东西"，但它们在类型系统层面走的是两条完全不同的路：前者是编译期单体化（monomorphiza