Jeffery's Blog

红黑树里每一项是：价格 → 这一档的订单队列。

函数签名里不但写出返回类型，还给每个返回值起名字。这些名字在函数一进来就已经存在，零值可用，最后可以只写 return。

上一篇说红黑树只管价档。接着会撞上几个词：prices map、最值、后继、红或黑、O(log 档数)。它们对着同一件事：价格档位怎么找、怎么从上往下吃。

读内存撮合库时，很容易把红黑树想成「所有订单都挂在树上」。它不是。树只索引价档，不索引单笔订单。 键是价格，值是该价的 OrderQueue。找某一档用旁边的 prices map；树只负责「谁最贵 / 谁最便宜 / 下一档是谁」。

上一篇讲完质因子：0.1 在二进制里是无限循环。机器却只有 64 位，必须截成一个有限的近似。截的规则写在 IEEE 754 的这一行里：

1

值 ≈ ± (1.尾数) × 2^(指数 − 1023)

它不是新公式，就是二进制版的科学计数法，再配上「指数不能直接存负数」的偏移。

订单簿里不能用 float64 表示价格，常被一句话打发：「0.1 在二进制里写不完。」再往下追，就会撞上另一句：看分母的质因子，是不是都是这个进制基数也有的质因子。

这句话不绕。拆开只有三块：什么是质因子、进制的基数有哪些质因子、多出来的那个质因子会把小数变成无限循环。

在 Web 开发和系统架构设计中，身份验证（Authentication）是系统的基石。传统的基于 Session 或随机 Key 的 Token 机制与现代的 JWT（JSON Web Token）是两种最主流的方案。

然而，在面试和实际开发中，我们往往容易只看到 JWT 的便捷，而忽略了它的适用边界。本文将从无状态验证、存储开销、时效控制等维度，深度剖析 JWT 的优势与致命缺陷。

在 Go 语言的面试中，关于高并发和协程（Goroutine）控制，有一个非常经典且极易答错的细节题：

“当一个父 Context 被取消时，监听它以及监听它子 Context 的多个协程，是按照什么顺序退出的？是父协程先退出，还是子协程先退出？”

许多开发者第一直觉会回答“自上而下顺次退出”或“自下而上逆序退出”。然而，正确答案是：完全乱序退出，且不存在任何确定的先后顺序。

本文将借助 Go 底层调试神器 go tool trace 的微秒级跟踪视图，还原并剖析这背后的 GMP 调度核心机制。

在近期针对 Hexo 博客的分支管理、PR 合并以及 Redefine 主题配置的调整中，遇到并解决了一些涉及 Git 版本回退与工作区冲突拦截的问题。

本文将这些踩坑记录及底层的技术逻辑进行简要复盘，以备后查。