这篇是个人踩坑记录：双系统（Ubuntu + Windows）场景里，Windows 引导偶发丢失时如何恢复。 场景 双系统环境下，Windows 启动项异常消失 常见触发原因包括系统自修复、分区调整、引导项被覆盖等 修复准备 一块可启动的 Windows 安装 U 盘 从 U 盘启动，进入“疑难解答 -> 命令提示符” 修复步骤 diskpart list disk select disk 0 list part list vol select volume <EFI分区卷号> assign letter=K: exit bcdboot C:\Windows /s K: /f UEFI /l zh-cn 执行完成后重启，通常即可恢复 Windows 引导。 经验备注 关键点是定位正确的 EFI 分区并挂载盘符 bcdboot 是重建引导文件的核心命令 如果机器有多块硬盘，select disk / select volume 要结合实际确认，避免误操作 这类操作有系统级风险，建议先备份重要数据再处理。
ripgrep（命令是 rg）是一个命令行搜索工具，支持递归搜索和正则匹配。它速度快、体验好，并且会尊重 .gitignore，对代码仓库尤其友好。 安装 可以按你的操作系统安装，安装后用下面命令确认： rg --version 常用命令 1) 当前目录递归搜索 rg pattern 2) 按文件类型搜索 rg pattern -tjs 3) 忽略大小写 rg -i pattern 4) 统计匹配次数 rg -c pattern 5) 只输出命中文件名 rg -l pattern 6) 反向匹配（不包含 pattern） rg -v pattern 7) 按完整单词匹配 rg -w pattern 8) 指定搜索目录 rg pattern /path/to/search 9) 从文件读取多个搜索模式 rg -f patterns.txt 10) 与其他命令组合 统计命中文件数量： rg -l pattern | wc -l 进一步帮助 rg --help 如果你的主要工作是“在代码仓里快速定位信息”，rg 值得作为默认搜索工具。
LLM可观测性 与传统微服务应用所关注的黄金三指标（请求数，错误，耗时）类比，我们认为 AI 应用的黄金三指标可能是 Token，Error，Duration。 耗时主要关注的是模型推理延迟，也就是在推理过程中我们通常需要关注模型的首包延迟，即 TTFT(Time to first token)，这个指标反映了相应的速度，还有像 TPOT (Time Per Output Token) 反映生成的效率和流畅度。另外一个比较重要的指标就是吞吐率。吞吐率可以衡量我们这个模型本身，能够同时去支撑多少个推理请求。所以这几个指标是需要进行一些平衡的，三个指标不可能同时满足得特别好。 Token 可能是 AI 应用最重要的一个指标，所以每次请求会记录 Token 的消耗情况，甚至我们需要精确地区分 Input Token 和 Output Token 的消耗，因为大家知道模型的定价里面 Input Token 和 Output Token 是不一样的，我们在成本核算的时候，会将输入 Token 和输出 Token 分别进行统计。 耗时耗在哪？ ==> 全链路追踪 业务/应用层，还是推理引擎层？ 问答质量 我们要解决模型回答得好不好，每次模型的升级和优化，都需要建立一个基线，并且确保模型的迭代满足这个基线，否则回答的质量会导致用户体验受损。为此，我们把模型的 input/output 全部都采集到日志平台中，接下来我们可以筛选出一批记录，通过数据加工，引用外部的裁判员模型，对当前这个模型回答的输入输出结果进行一个评估。
技术一定是向着降低技术的门槛发展的，比如AI coding，降低了写代码的门槛，但也其实只是降低写代码这件事情本身，很多系统性的思考，系统设计的思想，AI是不能脑控你的，你得要自己理解why。 AI时期泡沫已经来了，不确定是不是泡沫的最高点，但是泡沫终会散去，怎么在这个时期保全自己？ 苦练基本功 把自己的能力与AI红利摘除，你不能是因为吃了AI红利而强，与AI强绑定的话，可能就完蛋了。 这一点其实也和上面绑定，也就是一致。 初稿：2026-04-25。若你读到与当下实践不一致的句子，以你现场约束为准；欢迎留言或 PR 指出可改进之处。
场景引入 如果你设计了一个类似 B 站的视频网站中的搜索系统，或许在初期 MySQL 的 like 模糊搜已经能满足你对视频的标题、简介的搜索需求。 SELECT * FROM videos WHERE title LIKE '%'||:search_term||'%' OR description LIKE '%'||:search_term||'%'; 如果后期系统视频的量级上来了，对性能有一定要求了，你或许已经开始考虑 ES 了。后面如果你还想让与搜索关键词相关的创作者名称、视频评论、关联标签也能级联视频搜出来，甚至弄一个各种业务维度的融合公式，那么 ES 这样的搜索引擎再适合不过了！ 但是，如果数据写一份 MySQL，还要落一份 ES 来支撑筛选/搜索，要怎么写入两个异构的存储系统、并保证它们的一致性呢？ [!NOTE] 如果你有更好的场景欢迎提出/补充～ 方案一：同步双写 优点 简单粗暴 ES 同步写入快 缺点 业务耦合，扩展性差，代码侵入性强（要在写 MySQL 的地方后写 ES 的代码，要在代码设计上做好收敛） 影响性能，写入两个存储，响应时间变长（本来 MySQL 的写入性能不是很高，再加一个 ES，系统的性能必然会下降），吞吐也会下降 存在双写失败丢数据风险（比如写完MySQL，ES 就挂了） 方案二：异步双写 优点 性能高 不易出现数据丢失问题，主要基于 MQ 消息的消费保障机制，比如 ES 宕机或者写入失败，还能重新消费 MQ 消息 多源写入之间相互隔离（业务侧只管发消息），解耦数据生产者和消费者，便于扩展更多的数据源写入 缺点 同样存在业务耦合的问题，写完 DB 之后，还需要发个 MQ（代码设计上做好收敛，也可以关注一下所用 orm 框架有没有 hook 之类的能力，支持你“写后 xxx”） 接入新的数据源需要实现新的消费者代码 系统复杂度增加，引入了消息中间件 MQ是异步消费模型，存在延迟问题 [!tip] MQ 可以缓冲和 DB 的负载能力不一致问题 ...
大 key 标准 在一般的业务场景下（并发和容量要求都不大）： 单个string的value＞1MB 容器ds元素数量超过10000 在高并发且低延迟的场景中：（互联网上看到比较多的版本） 单个string的value＞10KB 容器ds元素数量超过5000或整体value>10MB 阿里云的云版本Redis： Key本身的数据量过大：一个String类型的Key，它的值为5MB Key中的成员数过多：一个ZSET类型的Key，它的成员数量为10000个 Key中成员的数据量过大：一个Hash类型的Key，它的成员数量虽然只有1000个但这些成员的Value（值）总大小为100MB 但其实Redis大key问题的定义及评判准则并非一成不变，没有固定的判别标准，还是要根据Redis在实际业务中的使用来综合评估。（注意边界问题） 大 key 影响 读取成本高 时延（执行命令时间更长） 带宽（大 key 消耗更多的带宽，从而影响相关服务） 大key的写操作容易阻塞，从而导致无法正常响应 慢查询 主从同步异常 占更多的存储空间，从而导致逐出，甚至是 OOM（Out Of Memory） 集群架构下，某个数据分片的内存使用率远超其他数据分片，即数据分片的内存资源不均衡 [!DANGER] 根本原因 Redis 是单线程！ 大 key 产生原因 业务设计不合理。这是最常见的原因，不经过合理拆分，就直接把大json塞在一个key中；甚至塞二进制文件数据。 没有处理好value的动态增长问题。如果一直添加value数据，没有定期的删除机制、合理的过期机制或者卡量，大key只是早晚的问题。（例如：微博明星的粉丝列表、热门评论、直播弹幕等） 程序bug。某些异常情况导致某些key的生命周期超出预期，或者value数量异常增长。比如LIST的业务消费侧发生代码故障，造成对应Key的成员只增不减。 找到大 key bigkeys 参数 参考官方文档：https://redis.io/docs/latest/develop/connect/cli/#scanning-for-big-keys 使用redis-cli命令客户端，连接Redis服务的时候，加上 --bigkeys 参数，可以以遍历的方式分析Redis实例中的所有Key，并返回Key的整体统计信息与每个数据类型中Top1的大Key。（原理是基于SCAN） $ redis-cli --bigkeys # Scanning the entire keyspace to find biggest keys as well as # average sizes per key type. You can use -i 0.01 to sleep 0.01 sec # per SCAN command (not usually needed). [00.00%] Biggest string found so far 'key-419' with 3 bytes [05.14%] Biggest list found so far 'mylist' with 100004 items [35.77%] Biggest string found so far 'counter:__rand_int__' with 6 bytes [73.91%] Biggest hash found so far 'myobject' with 3 fields -------- summary ------- Sampled 506 keys in the keyspace! Total key length in bytes is 3452 (avg len 6.82) Biggest string found 'counter:__rand_int__' has 6 bytes Biggest list found 'mylist' has 100004 items Biggest hash found 'myobject' has 3 fields 504 strings with 1403 bytes (99.60% of keys, avg size 2.78) 1 lists with 100004 items (00.20% of keys, avg size 100004.00) 0 sets with 0 members (00.00% of keys, avg size 0.00) 1 hashs with 3 fields (00.20% of keys, avg size 3.00) 0 zsets with 0 members (00.00% of keys, avg size 0.00) [!TIP] 总结 ...
例题 使用主定理 主定理是一个强大的工具，用于解决递归关系式，通常用于分析某些递归算法的时间复杂度。当递归关系式具有以下形式时： ...
设计模式 举个例子，比如我们有个导出功能，按照不同的格式导出数据，比如 CSV、Excel、JSON 等；比如我们需要导入 execl 文件，需要解析文件内容，针对不同的格式，需要不同的解析方式；再比如我们有一个给用户发送邮件功能，有可能需要用 gmail, qq, 163 等邮箱服务商，手机验证码服务也是如此。如果我们使用 if-else 或者 switch-case 来实现，代码会变得很臃肿，而且扩展性很差，多一个导出为其他格式的需求，就需要大量修改代码。 处理之前的代码可能长这样： /** * @param filePath 文件路径（含文件名） * * 导出 CSV 和 Excel 的需求 */ public void export(String filePath) { String fileType = filePath.substring(filePath.lastIndexOf(".") + 1); if ("csv".equals(fileType)) { // 导出 CSV 的具体代码，以下省略100行 } else if ("excel".equals(fileType)) { // 导出 Excel 的具体代码，以下省略100行 } else { throw new IllegalArgumentException("不支持的文件类型：" + fileType); } } 策略模式 策略模式的主要作用是用来提升一些代码的复用性的，或者解决代码中出现很多 if-else 语句的问题。 ...