[ LATEST LOG ]
PAGE 4 / 5
写 Rust 时，很多人第一次卡住的地方不是所有权，而是 ?。代码看起来只是把错误往上抛，编译器却报出 the trait bound ... From<...> is not implemented；改成 fn main() -> Result<(), Box<dyn Error>> 后能编译了，运行时又只打印一行看不懂的 Debug。要解决这些问题，需要先弄清 ? 到底做了什么。
? 展开后只做两件事下面这行代码：
1let port = read_port()?;很多表单在提交前都有一段相似的 JavaScript：遍历输入框、判断空值、用正则表达式验证邮箱、比较两次密码，再给每个字段插入一行红字。代码越堆越多，提示文案和浏览器自带的气泡还不一致。
其实 HTML 早就内置了一套约束校验（Constraint Validation）。只要把规则写在标签上，浏览器就会负责拦截提交、聚焦第一个出错的字段，并显示本地化提示。JavaScript 只需要处理那些真正需要自定义的部分。
下面这些属性和输入类型，都会自动参与校验：
凌晨两点，同步脚本跑完了。日志里一串红色报错，但脚本继续往下执行，最后打印出「完成，成功 0 个文件」，退出码 0。CI 显示绿色，直到第二天业务方问：数据怎么没更新？
问题不在 Copy-Item，而在于 PowerShell 的错误模型和大多数人的直觉不一样：不是所有错误都会中断执行，也不是所有错误都能被 try/catch 捕获。这篇文章从最小复现开始，把这件事讲清楚。
PowerShell 把错误分成两类：
lru_cache 是 Python 标准库里最容易被随手加上的优化之一。给一个慢函数套上装饰器，命中率看起来也不错，于是代码上线。直到某天发现内存只涨不降，或者接口返回了旧数据，才回头检查这个装饰器。
它确实好用，但它的行为边界比多数人以为的要窄。下面这五个坑，基本覆盖了日常使用中最容易出问题的地方。
lru_cache 的本质是：用位置参数和关键字参数拼出来的键去查一个字典，命中就直接返回旧结果，未命中才执行函数体。
改完一个模块里的常量，重启脚本，输出还是旧值；在 Jupyter 里调整了函数，调用结果纹丝不动；线上服务报 ModuleNotFoundError，本地却一切正常。这些问题的根源大多不在代码逻辑，而在 import 背后那套缓存与路径规则。
这篇文章不讲语法，只讲排查：import 到底做了什么，以及几类"代码明明改了却不生效"的典型场景。
import 只执行一次Python 的 import 语句在真正加载模块前，会先查一个全局字典 sys.modules。命中就直接返回，模块代码不会再执行第二遍。
先看一个真实场景：你维护一个基础库 libfoo.so，某次在类里加了一个成员变量，重新编译发布。调用方的代码一行没改，也没有重新编译，启动后却在析构 std::string 时崩溃。日志、单元测试、内存检查工具都正常，问题只在“新旧二进制混跑”时出现。
这类问题通常不是逻辑 bug，而是 ABI 被破坏了。本文以 Linux + GCC/Clang 为例，梳理 C++ ABI 的边界、常见破坏点和可落地的防护手段。
ABI（Application Binary Interface）是二进制层面的契约，包含：
一台 2 核 2G 的小型服务器上跑着 Nginx、Gunicorn 和 Redis。最近每隔两三天，就有一个 Python worker 突然消失，应用日志里没有任何异常，SSH 却还能正常登录。这不是程序自己退出，而是被内核的 OOM Killer 杀掉了。
本文按实际排查顺序，从确认内存状态到定位 cgroup 限制，整理一套可复用的命令。
登录后第一件事通常是看 free：
服务运行几天后，日志里开始出现：
1OSError: [Errno 24] Too many open files很多人第一反应是“磁盘满了”或“文件太多”，但在 Linux 中，文件描述符（FD）不只代表普通文件。socket、pipe、epoll、eventfd、inotify、signalfd 都会占用 FD。因此这句话的真实含义往往是：进程打开的连接、管道或事件对象，已经达到上限。
这周的主要工作只有一件：把一个运行了两年多的 Python 服务从 pip + venv + requirements.txt 迁移到 uv。动机很实际：CI 里安装依赖要三分半，requirements.txt 又没锁版本，同一个 commit 两次构建偶尔会装出不同的包。周五收工时，冷启动降到 40 秒以内，还顺带改掉了 Dockerfile 和 GitHub Actions。这篇周报记录过程、遇到的问题和最终数据。
动手前先测量，否则一周后说不清到底快了多少。我在本机和 CI 上各跑三次，取中位数：
1python -m venv .venv凌晨收到监控告警：根分区使用率 96%。登录服务器后 df -h 显示 / 确实快满了，但用 du 扫描却找不到对应的大文件。这种“空间对不上”的情况在 Linux 上很常见，原因通常不止一种。下面按从易到难的顺序梳理一遍排查流程。