Coldin04's Blog

借助 Karabiner，按需唤醒豆包输入法

Sun, 24 May 2026 23:34:42 +0800

请注意，本文章由AI代写，语句可能存在不通顺或者啰唆等情况，我会有空时进行优化。

今天早上装了豆包输入法。起因很简单——看了一些关于它语音后处理的讨论，好奇一个外挂了小语言模型的输入法，在语音转文字这件事上到底能做到什么程度。试了一圈下来，识别准确率和文本优化确实超出了预期。不过我没打算把它设为主力输入法。日常打字我还是习惯 Rime / 鼠须管，无论手感还是隐私考量都更顺手。所以策略很明确：打字归 Rime，说话归豆包。

但问题也跟来了。豆包的语音输入只有在豆包输入法本身处于激活状态时才稳定——这意味着每次想用语音，得先手动切到豆包，用完再切回去。一次两次还好，频繁操作就很打断节奏。我需要一个更轻的方式，把"切换→语音→切回"这个流程压缩成一次操作。

之前其实写过一篇关于豆包输入法整体体验的文章（《用嘴写 Prompt：豆包输入法如何成为我与 AI 对话的「语音中介」》），聊的是语音后处理的价值和工作流整合。这篇不重复那些，只聚焦一个问题：怎么用 Karabiner 把豆包当成一个"随叫随走"的语音工具。

想清楚要做什么

需求拆开来看其实就三步：切到豆包、触发语音、用完切回 Rime。如果再加一个约束——不引入新的常驻工具，只在已有的 Karabiner-Elements 里解决——那就变成了一个 Karabiner 规则设计问题。

键位选择上没太多纠结。右 Command 平时几乎不用，不跟 Fn / Globe 的系统切换打架，也不影响我 Caps Lock 上已有的组合规则。交互逻辑也很快定下来：双击右 Command，第一次唤醒语音，第二次结束并切回。

真正让我折腾了一下午的，是第二步——“触发语音"这四个字。

右 Option 双击，到底谁来发

豆包输入法的语音输入，默认通过双击右 Option 唤醒。问题在于，不是随便一个"右 Option"它都认。

我最先用 osascript 模拟 key code 61 试了一下。按键确实发出去了，但豆包毫无反应，就像什么都没收到一样。然后换成 Swift 写了个小工具，用 CGEvent 来发右 Option——这次偶尔能唤醒，但十次里大概只有三四次成功，完全不可靠。

最后用 Karabiner 自己的 to 规则直接发 right_option，一次就通了。

这个差异其实挺有意思的。osascript 的 System Events、CGEvent 的底层事件、Karabiner 发出的按键——它们走的是不同的事件通道和处理层级。豆包显然在某个层面做了过滤，只认 Karabiner 那种更"原生"的按键事件。具体是内核扩展层级的问题还是输入法进程的优先级问题，我没有深挖，但结论很清楚：右 Option 双击必须由 Karabiner 直接发，不能绕道外部脚本或工具。

这个发现也让后续方案简化了不少。既然按键模拟只能交给 Karabiner，那输入法切换也干脆用 Karabiner 内置的 select_input_source，整条链路都在一个工具里闭环。

规则是怎么搭起来的

方案的核心是两个变量：right_command_tapped_once 标记右 Command 是否已经被单按过一次（用于判断是不是双击），doubao_voice_active 记录当前是否在语音流程中。

整个规则拆成三段。第一段处理"激活语音”：当系统检测到双击右 Command、且当前不在语音状态时，依次执行切到豆包、等待 300 毫秒让输入法完成切换、发送右 Option 双击唤醒语音，最后把状态变量置位。

第二段处理"退出语音"：在语音状态下再次双击右 Command，先发一次右 Option 双击让豆包结束当前语音并进入文本处理，然后等 5 秒让它完成优化，最后切回 Rime 并清掉状态变量。

第三段是双击识别的基础——利用 Karabiner 的 to_if_alone 机制，单按右 Command 时把 right_command_tapped_once 设为 1。如果用户在超时时间内再次按下右 Command，前两段规则就会根据状态变量判断该走激活还是退出。

flowchart TD
 A[双击右 Command] --> B{doubao_voice_active = 1？}
 B -->|否| C[select_input_source 切到豆包]
 C --> D[等待 300ms]
 D --> E[发送右 Option 双击]
 E --> F[标记 doubao_voice_active = 1]
 B -->|是| G[发送右 Option 双击]
 G --> H[等待 5000ms，给豆包整理文本]
 H --> I[select_input_source 切回 Rime]
 I --> J[清除 doubao_voice_active]

完整规则已经发布到 Karabiner-Elements 的 Complex Modifications 规则市场：Double tap Right Command switch DoubaoIME。打开链接后点击 Import，按 Karabiner 的提示导入并启用即可。

如果你想根据自己的习惯调整规则（例如更换触发键、修改输入法 ID 或调整等待延迟），可以在 Karabiner 导入后修改对应参数，也可以将这篇文章链接交给 AI（如 ChatGPT 或 Claude），让它参考这个逻辑为你生成定制化配置。

这套规则的核心价值在于实现了一个全局快速唤醒的工作流：无论你在哪个 App 下，只需双击右 Command 即可瞬间切到豆包并开启语音输入，说完再次双击即可自动切回主力输入法（如 Rime），将“切换→语音→切回”的繁琐操作压缩成了一个连贯的交互。

两个等待，各有用意

规则里有两处 vk_none 配合 hold_down_milliseconds 做的等待，一开始可能觉得多余，实际上各有各的必要。

第一个 300 毫秒在切到豆包之后、发右 Option 之前。输入法切换不是瞬间完成的——如果按键发得太急，豆包还没完全激活，右 Option 事件就会被吞掉。300 毫秒是个经验值，我的机器上没出过问题。如果你的 Mac 比较老或者后台比较重，可以适当调大。

第二个 5 秒在退出时。最早我试过秒切——语音结束立刻切回 Rime——结果发现豆包经常只输出了一半，文本优化根本没做完。后来改成了先等 5 秒再切，问题就消失了。这个值可以根据习惯调：通常说短句三四秒就够了，长篇大论可能需要八秒。觉得慢就调小，发现切回去还是半成品就调大，没什么神秘的地方。

关于方案选型

中间也纠结过要不要用 Hammerspoon。它能力确实更强，能监听按键的按下和释放事件，写一个完整的状态机完全没问题。但需求本身并不复杂——就是双击切换加两个等待——为了这个让 Hammerspoon 常驻在后台，有点杀鸡用牛刀的感觉。而且实测下来，Karabiner 直接发的 right_option 是唯一能稳定唤醒豆包的方式，换成 Hammerspoon 反而可能重蹈 CGEvent 的覆辙。

Shell 脚本也是类似的情况。一开始打算用 macism 做输入法切换，osascript 发按键，但因为右 Option 的模拟问题，这条路一开始就走不通。目前这版完全不依赖外部脚本，切换直接用 Karabiner 内置的 select_input_source。如果后面发现 select_input_source 在某些 macOS 版本上不稳定，也随时可以退回去调用 shell_command 执行 macism——但右 Option 双击一定得留在 Karabiner 这边。

这个方案用了一下午，跑了十几轮语音输入，目前没出过岔子。如果你也面临类似的需求——主力输入法不想换，但偶尔想用豆包语音——可以参考这个思路。导入后的规则里把 input_source_id 改成你自己的输入法就行，等待时间按习惯微调，其他的应该都能直接用。

本文方案由作者亲自实验，文章整理交由AI辅助完成 *

用嘴写 Prompt：豆包输入法如何成为我与 AI 对话的「语音中介」

Sun, 24 May 2026 17:09:57 +0800

请注意，本文章由AI代写，语句可能存在不通顺或者啰唆等情况，我会有空时进行优化。

今天早上突发奇想：如果我把自己跟 AI 聊天时的输入场景，全部切换到豆包输入法的语音输入，会怎样？结果比预期的好用得多——尤其是它的自动纠错和后处理能力。于是我顺势用它来写 Prompt，一路写到了现在。这篇文章，既是评测，也是实验报告。

引子：Prompt 的本质，是把话说清楚

先说一个可能有点反直觉的观点：好的 Prompt，不是靠堆砌「扮演一个专家」「请一步步思考」这类奇技淫巧堆出来的。好的 Prompt，是把你的需求表达清楚。

思路清晰的人，哪怕用最直白的语言描述需求，AI 也能准确理解。反之，思路混乱的人，套再多 Prompt 模板也救不回来。

问题在于：把思路转化为详尽、有清晰逻辑的文字，这个过程本身就有摩擦。 尤其是在灵感涌上来的时候，打字的速度远远跟不上思考的速度。你脑子里已经跑完三圈了，手还卡在第一句话的措辞上。

这其实不是新问题。几年前有一款叫 Typeless 的产品，它的核心洞察就是这个——人们需要一个能快速把思维「倾倒」出来的工具，而不是一个功能丰富的排版软件。Typeless 后来没有成为大众产品，但它埋下了一颗种子：输入工具的未来，不是让打字更「强大」，而是让打字这件事本身变得更「轻」。

豆包输入法，以及最近一批新一代 AI 输入法的出现，某种程度上就是这颗种子在语音输入领域的引爆点。

所以今天早上我决定做一个小实验：把跟 AI 聊天时的输入法切换到豆包，全程用语音输入 Prompt。下面是这次实验的完整记录和思考。

一、我的键盘策略：日常打字 vs 语音输入

先交代背景。

在今天之前，我的日常打字键盘随设备而变：电脑设备上用 Rime（中州韵），开源、可定制、隐私可控；手机上，同时使用 Google 键盘（Gboard） 和 iOS 原生键盘。这三者本质上是一回事——它们只是「日常打字键盘」这个角色在不同设备上的不同面孔，没有哪一块跟「AI 语音输入」扯得上关系。

然后今天早上，我新装了豆包输入法。不是因为它打字比 Rime 更好用，纯粹是想体验一下——一个外挂了小语言模型做后处理的语音输入法，到底能准到什么程度？尤其是在给 AI 写 Prompt 这个场景下，能不能用？

所以现在我的键盘实际上只分两类：

角色输入法场景日常打字Rime / Gboard / iOS 原生（随设备而定）打字、密码、私密聊天、文档语音输入豆包输入法（新装）走路、旅行、大段输出、跟 AI 快速对话

简单来说：打字归日常键盘，说话归豆包。 豆包是第一个不以「打字体验」为核心、而是以「语音后处理」为核心加入我阵容的输入法。正因为它是新装的、带着明确实验目的来的，所以我能更客观地判断：它到底解决了什么问题，以及它想要什么回报。

它还不是完美的

不过诚实地说，体验了一天，也发现了几个明显的短板。

首先是键盘打字的粘滞感。如果你习惯 Rime 或 iOS 原生键盘那种干脆利落的打字手感，切换到豆包输入法时会明显感到一种迟滞——按键反馈不够跟手，快速输入时有轻微的粘滞。不是那种「完全不能用」的糟糕，但足以让你在日常打字时坚持留在日常键盘上。换句话说，豆包输入法在键盘输入体验上，目前还完全替代不了 Rime 或自带键盘。它唯一让我愿意切换过来的理由，就是语音输入。

其次是语音识别的边界。准确率整体不错，但有几个痛点：自定义词汇缺失——像「Rime 输入法」这种相对小众的专有名词，几乎每次都会被听成「Remi 输入法」，系统也没有提供便捷的自定义词库入口来纠正；中英文混说时英文单词的识别准确率明显下降；对于一些新出现的、使用频率不高的词汇，模型显然还没有覆盖到。这其实也是当前 AI 语音识别的通病——主流场景表现好，边缘场景容易翻车。

还有输入法切换的摩擦。在日常键盘和豆包之间频繁切换，操作上确实不够方便。iOS 上需要通过长按地球图标手动选择，每次切换都是一次微小的中断。这个问题不完全是豆包的锅，更多是系统层面的限制，但作为用户，体验是真实存在的。

这些短板让我不会把豆包输入法设为主力键盘。但恰恰相反——正是因为它在语音后处理这个长板上做得足够好，我才会容忍这些短板继续用它。接下来的内容，就全部围绕这个长板展开。

二、两种场景：语音输入解决的真实痛点

场景一：在路上回复跨平台消息

微信自带的语音转文字其实还不错。但问题在于——我只在微信里用微信。当我在 Telegram、Discord 或者 Signal 上收到消息时，系统自带的听写就成了唯一选择。

而在走路、提东西、或者单纯不想停下来打字的时候，一个能跨 App 使用的语音输入法就成了刚需。豆包输入法在这里的优势很简单：任何能调出键盘的地方，就能语音输入。 不需要切换 App，不需要复制粘贴。

场景二：天马行空跟 AI 聊天时，打字跟不上脑子

这是我认为更重要的场景。

不知道你有没有过这种体验：脑子里有一个模糊但有趣的想法，想丢给 AI 聊一聊。但当你坐下来打字的时候——

第一句写了一半，后面的思路就散了
修修改改，发现十分钟过去了还没把 Prompt 发出去
最糟的是，那个最初的想法在修改过程中被自己「理性化」了，失去了原本的野性

这时候语音输入的价值就体现出来了。说话的速度大约是打字的 3-4 倍，而且说出来的时候，思维是连续流动的，不会被单个字词的修改打断。

我之前的做法是用 Apple 听写，或者直接使用 Gemini/ChatGPT App 自带的语音输入。但问题是——它们能听清你在说什么，却不理解你在说什么。

三、原生听写 vs AI 输入法：不是「听写」，而是「理解」

这是整篇文章最核心的观点。

Apple 的听写、Gemini 的语音输入，本质上做的是同一件事：忠实转录。你说什么，它就记什么。听起来没错，但在实践中，问题在于：

口语和书面语天然有差距。 我们说话时会不自觉地带上「嗯」「就是」「那个那个」——忠实转录会把这些全保留下来，导致一段 Prompt 看起来像脱口秀草稿。
同音词完全依赖声学模型。 「Rime 输入法」和「Remi 输入法」，在声学层面几乎无法区分。忠实转录不会帮你纠正，而 AI 后处理可以根据上下文推断。
人类的即兴表达是有「毛边」的。 我们边说边组织语言，句子结构往往头重脚轻、前后颠倒。忠实转录保留这些毛边，AI 后处理可以帮你「熨平」。

豆包输入法的做法不同：

语音识别 → 小语言模型后处理 → 输出优化后的文本

它不只是把你说的转成字，而是在转录结束后，整体性地优化词句，让它读起来像「写出来的」而不是「说出来的」。包括：

根据上下文修复同音错别字
去除口语填充词
调整语序使其更符合书面表达
智能断句和标点

换句话说，原生听写给你的是草稿，AI 输入法给你的是成品。

对于 Prompt 来说，这一点尤为重要。因为 Prompt 的质量直接决定 AI 输出的质量——一个充满口语毛边的 Prompt 和一个通顺清晰的 Prompt，可能得到完全不同的回答。你不需要学「Prompt 工程」，你只需要把话说清楚。而豆包输入法帮你做的，就是让「说出来的话」变成「写清楚的文字」。

四、从万象拼音到豆包输入法：模型驱动的输入革命

这里我想引入一个有趣的类比：Rime 的万象拼音方案。

Rime（中州韵）是一个开源输入法引擎，万象拼音是其中一个拼音输入方案。它的核心思路是什么？

传统拼音输入法：规则驱动（白盒）—— 手动维护词库、拼音表、纠错规则
万象拼音：模型驱动（黑盒）—— 通过类似语言模型的方式，根据上下文预测用户下一个要打的词

这和豆包输入法的思路惊人地相似。两者的共同逻辑是：

传统方案新方案拼音输入规则匹配词库万象拼音：模型预测语音输入声学模型 + 逐字转录豆包输入法：转录 + LLM 后处理

这其实反映了一个更大的趋势：输入法的进化方向，是从「忠实记录」到「理解意图」。

当然，有人会担心黑盒模型的不可预测性。规则系统虽然僵硬，但至少你知道它什么时候会出错、为什么会出错。模型系统像一个「输入黑箱」，你不知道它会把你的「万象拼音」理解成正确的词，还是自作主张地「润色」成另一句话。

但我的态度是：在复杂场景下，黑盒往往比白盒更有优势。 白盒需要大量的人力去写规则、维护词库、穷举边界情况，而模型可以通过数据自动习得这些。尤其是在长语句输入、AI Prompt 场景下，白盒规则很难覆盖人类表达的多样性，而黑盒模型恰好擅长处理这种「模糊但合理」的映射。

五、字节的算盘：语音是触达非豆包用户的暗线

说了这么多用户体验的好话，也该聊聊「代价」。

豆包输入法是免费的。字节不是慈善机构。它的商业逻辑其实很清楚：

触达非豆包用户。 像我这样的人——用 Claude、ChatGPT、Gemini，但不愿意用豆包——字节通过输入法照样能接触到我们。输入法是比 AI 助手更底层的入口，只要你在打字，你就绕不开它。
收集 Prompt 级语料。 用户通过语音输入的 Prompt、聊天内容、搜索关键词，都是极其高质量的训练数据。尤其是 Prompt——它直接反映了用户想要什么、怎么表达需求。这对于优化豆包模型本身、或者构建用户意图理解能力，都有巨大价值。即使用户用的是 Claude 而不是豆包，字节依然能通过输入法了解到「用户是怎么跟 AI 说话的」。
用户画像与个性化。 输入法天然能了解你的语言习惯、常用词汇、表达风格。即使用户不在字节的生态里（不用豆包、不用抖音、不用头条），输入法依然可以成为拼图的一块。

这对用户来说意味着什么？我的看法是：这是一笔需要「知情」的交易，而不是需要「拒绝」的交易。

字节不是偷偷摸摸地在做这件事。输入法需要联网才能使用云端语音识别和 AI 后处理，这是功能上的必要代价——就像你用 Gboard 的语音输入，Google 也会收到你的语音数据一样。

关键在于，你是否清楚自己在交换什么，以及是否有选择地控制这种交换。

六、我的选择：「数据分区」而非「数据拒绝」

回到开头提到的键盘策略。

我完全可以在手机上只装 Rime，所有场景都拒绝被收集数据。但我不这么做，因为我觉得有些场景下，语音输入的效率提升远大于数据隐私的代价。

我在走路时回复一条 Telegram 消息——这不会泄露什么惊天秘密，但停下来打字会打断我的节奏。
我突然有一个天马行空的想法想和 Claude 聊聊——说五分钟的话就能产出几百字的 Prompt，这创造的价值远超字节可能从中提取的几条语料。

而对于日常的打字——尤其是在输入密码、私人聊天、工作文档时——我切回 Rime 或 iOS 原生键盘。

这就像你不会在家门口修一堵防火墙，但你会给卧室装窗帘。数据隐私不是非黑即白的开关，而是根据场景调节的旋钮。

七、我的写作工作流：从 Cyime 到豆包输入法

聊完输入，再聊聊输出。这篇文章是怎么被「生产」出来的？我的完整工作流是这样的：

1. 语音倾倒 → 豆包输入法

我先用豆包输入法的语音输入，把脑子里关于这篇文章的所有想法一股脑说出来。不需要组织语言，不需要在乎措辞——就是把思维「倾倒」出来。豆包输入法的后处理会帮我自动整理成通顺的文字。

这一步解决的是「从零到草稿」的摩擦力。

2. AI 辅助整理 → Cyime + MCP

草稿有了之后，我把它丢到我正在用的编辑器 —— Cyime(青柠写) 里面。

当然，欢迎访问 https://github.com/Coldin04/Cyime 了解这个项目。

Cyime 是我自己用两个月时间写的一个 Web 编辑器，基于 Tiptap 构建，原生支持 Markdown 语法。它有两个我认为很实用的特性：

图片存储的「私有一键转公开」：文章里粘贴的图片默认存在 Cloudflare R2（私有云存储），安全可控。当你需要导出并发布到博客的时候，可以一键将图片批量上传到公开图床，省去了手动搬图的麻烦。换句话说，写的时候是隐私的本地工作区，发布的时候是无缝切换的公开环境。
内置 AI MCP 和 Skill 支持：这是前两天刚加的新功能。Cyime 集成了 MCP（Model Context Protocol），可以直接调用 AI 来辅助写作——比如你现在正在读的这篇文章，我就是在 Cyime 里把语音转录的原始草稿交给 AI，让它帮我整理结构、展开论点、润色表达。

这里我想特别说明一下，避免误解：AI 在这里的角色是「整理者」，不是「创作者」。 文章的所有观点、素材、逻辑框架和表达语气都来自我自己——AI 只是帮我省去了「把散乱的草稿组织成通顺文章」这个体力活。这和「洗稿」有本质区别：洗稿是用 AI 把他人的内容换一种说法，而我的做法是用 AI 把自己的内容整理得更清晰。创意的源头和最终审校权始终在自己手里。

3. 人工审校 → 导出发布

AI 整理完之后，我在 Cyime 里做最后一轮修改——调整语气、补充细节、删掉 AI 产生的不准确表达。确认无误后，利用 Cyime 的导出功能，一键处理图片并发布到博客。

整个流程的核心哲学是：把人的精力集中在「思考」和「审校」两个高价值环节，把「打字」和「排版」两个低价值环节交给工具。

而这个流程得以跑通，豆包输入法在输入侧、Cyime 在编辑侧，各补上了一块关键的拼图。

八、声音正在成为思考的新界面

最后说一点展望。

过去写一篇博客，我需要在空白文档前坐很久，组织语言、斟酌词句、反复修改——大量的精力消耗在「写」这个行为本身，而不是「思考」。

而今天这套工作流让我的角色发生了转变：

豆包输入法 → 把声音变成草稿
AI（通过 Cyime MCP） → 把草稿整理成结构化的初稿
我 → 思考和最终审校

我发现自己从「打字员 + 编辑」变成了「思考者 + 最终审校」。而语音输入在其中扮演的角色不是「替代打字」，而是 「替代第一稿」 ——它消除了从脑海中的想法到纸面上的文字之间最痛苦的摩擦。

这让我想起一个观点：AI 时代的核心竞争力，不是「会不会写」，而是「会不会想」。 而语音输入 + AI 后处理，正在让「想」和「写」之间的距离缩短到几乎为零。

豆包输入法当然不是唯一在做这件事的产品。但它目前是我体验过的、在中文长句语音输入场景下做得最好的一个。至于字节借此收集了多少数据、优化了多少模型——那是他们的事。我在知情的前提下选择使用它，因为我觉得这笔交易划算。

而也许更值得关注的是：当声音成为思考的新界面，我们和 AI 之间的对话方式，会不会从根本上发生变化？

本文初稿使用豆包输入法语音输出原始想法，在 Cyime 中通过 MCP 辅助整理结构，经人工审校后完成。结论是：如果你用对了工具，往往能事半功倍的完成工作。

由JUnit单元测试实验开始，浅学 SpringBoot初始化和测试

Tue, 19 May 2026 22:48:20 +0800

前两周软件测试课上，老师借由JUnit，来介绍单元测试并予以实践。之前没怎么写过Java，也正好以此机会了解一下Java的基本语法。

在开始学习和实验前，我已经在电脑的本地环境中配置好JDK和基础的代码支持环境，这里就不过多赘述。

基础介绍

什么是单元测试

单元测试是对软件中最的可测试单元（通常是一个法或类）进检查和验证的过程。在软件开发过程中，每实现个功能模块，就需要验证其是否正常作、是否达到预期效果。只有确保每个模块都正常工作，才能保证整个软件系统的平稳运行。

为什么需要JUnit

在没有JUnit之前，开发者通常通过编写main方法来测试代码。例如，测试一个计算器类的加法方法：

1
2
3
4
5
6


public class TestCalculator {
 public static void main(String[] args) {
 Calculator calculator = new Calculator();
 System.out.println(calculator.add(5, 5)); // 需要人工判断结果是否正确
 }
}

这种传统式存在明显弊端：需要动对比测试数据，法动化判断；当测试量很时，难以同时管理多个测试；测试代码与业务代码混在起，不利于维护。

JUnit是Java领域最流的单元测试框架，它能帮助开发者简化测试流程，在编写代码的同时进单元测试，快速追踪问题原因，降低回归错误的难度。

借由测试框架，对于初学者来说，也能更好的规范相关测试行为，例如实验指导书中重点提到 @BeforeEach @BeforeAll @AfterEach @AfterAll ，在某些需要临时数据环境中，也可以方便的在单元测试或者整体的文件测试开始时添加，测试后及时清理。保证相关数据相对隔离，不会因为某些情况下忘记清理异常数据或者添加数据而导致的测试额外问题，也减轻了测试者在每次测试前后的负担。

环境配置

原实验档案建议使用IDEA创建Spring项目，方便快速配置环境、配置依赖。不过我个人认为，为了这一个简单的单元测试引入整个重型IDE，不太是我的风格，我便使用了更简单的方法完成环境的初始化。

实际上SpringBoot 也可以通过官方的 https://start.spring.io/ 快速初始化，界面如下，通过相关页面，可以快速生成需要的项目脚手架，大大节省时间。

当然，也可以使用命令行工具快速创建项目，我创建的试验项目，列表如下所示：

1
2
3
4
5


curl https://start.aliyun.com/starter.tgz \
 -d groupId=com.cold04 \
 -d artifactId=junit-lab \
 -d dependencies=web \
 -d baseDir=junit-lab | tar -xzvf -

创建完成后，可以看到相关文件既创建成功。接下来是完成Lab相关的习题。

计数器练习

使用命令快速创建相关函数文件，要求的是实现一个简易计算器项目，并分别对相关函数进行测试。

1
2


mkdir -p src/main/java/com/cold04/junitlab/calculator
mkdir -p src/test/java/com/cold04/junitlab/calculator

首先创建Calculator.java文件，相关代码如下所示

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26


package com.cold04.calculator;

public class Calculator {
 // 加法
 public int add(int a, int b) {
 return a + b;
 }

 // 减法
 public int subtract(int a, int b) {
 return a - b;
 }

 //乘法
 public int multiply(int a, int b) {
 return a * b;
 }

 //除法
 public double divide(int a, int b) {
 if(b == 0) {
 throw new IllegalArgumentException("除数不能为零");
 }
 return (double) a / b;
 }
}

接下来创建测试类文件，位于 src/test/java/com/cold04/calculator/CalculatorTest.java ，代码如下：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66


package com.cold04.calculator;

import org.junit.jupiter.api.*;
import static org.junit.jupiter.api.Assertions.*;

public class CalculatorTest {

 private Calculator calculator;

 @BeforeEach
 public void setUP() {
 calculator = new Calculator();
 System.out.println("初始化 Calculator 对象中");
 }

 @AfterEach
 public void tearDown() {
 System.out.println("测试方法执行完毕");
 }

 @BeforeAll
 public static void initAll() {
 System.out.println("所有测试方法执行前的初始化");
 }

 @AfterAll
 public static void tearDownAll() {
 System.out.println("所有测试方法执行后的清理");
 }

 @Test
 public void testAdd() {
 System.out.println("正在测试 add 方法");
 assertEquals(10, calculator.add(5, 5), "5 + 5 应该等于 10");
 assertEquals(0, calculator.add(-5, 5), "-5 + 5 应该等于 0");
 System.out.println("正在测试 add 方法的负数情况");
 assertEquals(-10, calculator.add(-5, -5), "-5 + -5 应该等于 -10");
 assertEquals(-5, calculator.add(-2, -3), "-2 + -3 应该等于 -5");
 }

 @Test
 public void testSubtract() {
 assertEquals(5, calculator.subtract(10, 5), "10 - 5 应该等于 5");
 assertEquals(0, calculator.subtract(5, 5), "5 - 5 应该等于 0");
 }

 @Test
 public void testMultiply() {
 assertEquals(25, calculator.multiply(5, 5), "5 * 5 应该等于 25");
 assertEquals(-15, calculator.multiply(-5, 3), "-5 * 3 应该等于 -15");
 }

 @Test
 public void testDivide() {
 assertEquals(2.0, calculator.divide(10, 5), "10 / 5 应该等于 2.0");
 assertEquals(2.5, calculator.divide(5, 2), "5 / 2 应该等于 2.5");
 }

 @Test
 public void testDivideByZero() {
 // 测试除以零的情况，应该抛出 IllegalArgumentException
 assertThrows(IllegalArgumentException.class, () -> {
 calculator.divide(10, 0);
 }, "除以零应该抛出 IllegalArgumentException");
 }
}

此时，相关主要文件已经创建完毕，且可以开始运行并测试，使用 ./mvnw -Dtest=CalculatorTest test 指令既可开始测试。

测试和实验

基础测试

如下图所示，输入 ./mvnw -Dtest=CalculatorTest test 后，相关提示如下，显然测试通过。

修改断言，测试异常提示

如下图所示，这边假testMultiply 中 -5 * 3 因为测试者的忽视，意外写错-15，再次运行测试。如下图，可显然看到，测试在运行时指出了相关错误，但对于后续测试，是不影响的。对于测试前后的初始化调用，也不会因为某个单元测试不通过而停止。个人对此的理解是，测试前的环境准备和测试后的清理工作必不可少，例如在一些数据库环境中，在测试前写入相关mock数据，在测试后及时清理，避免数据异常影响下一阶段的测试或开发。这样的方式，显著的减少了开发时开发者的负担。

测试除以零的情况

在此情况下，我们的计算器会抛出 IllegalArgumentException 错误，显然我们需要在测试中捕获这个错误。当test文件成功捕获相关异常的时候，代表相关异常处理行为正常，测试通过（此处可能略微有点反逻辑，可以理解为这个地方是能不能判断出错误的位置，判断出就予以通过）。

字符串判断测试

完成了上述测试后，既趁热打铁，做一个如下要求的程序，并完善边界测试：

设计一个简单的字符串工具StringUtils，包含以下方法：

isEmpty(String str) ：判断字符串是否为空（null 或空字符串）

reverse(String str) ：反转字符串

concat(String str1, String str2) ：拼接两个字符串为该类编写完整的单元测试，要求：

使用 @BeforeEach 和 @AfterEach 注解

至少覆盖正常情况、边界情况和异常情况

使用至少 4 种不同的断言方法

代码准备

简单来说，这个程序的设计思路是：先写一个简单的工具类 StringUtils，把字符串相关的常用操作封装起来，然后用 JUnit 单元测试验证每个方法在不同输入下是否符合预期。代码如下：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


package com.cold04.stringutils;

public class StringUtils {

 public boolean isEmpty(String str) {
 return str == null || str.isEmpty();
 }

 public String reverse(String str) {
 if (str == null) {
 throw new IllegalArgumentException("字符串不能为 null");
 }
 return new StringBuilder(str).reverse().toString();
 }

 public String concat(String str1, String str2) {
 String first = str1 == null ? "" : str1;
 String second = str2 == null ? "" : str2;
 return first + second;
 }
}

测试设计

测试文件 StringUtilsTest.java 的设计思路是：按方法分别测试，每个方法只验证自己对应的功能，这样出错时能很快知道是哪一块有问题。

@BeforeEach 用来在每个测试方法执行前重新创建一个 StringUtils 对象。这样每个测试都是独立的，不会互相影响。@AfterEach 用来在每个测试结束后输出提示，方便观察测试执行顺序。

测试内容分成三类：

正常情况：比如 "hello" 反转成 "olleh"，两个普通字符串能正常拼接。这样验证基本功能是否正确。
边界情况：比如 null、空字符串 ""、单个字符 "a"。这些输入比较特殊，容易出错，所以要单独测。
异常情况：比如 reverse(null) 应该抛出 IllegalArgumentException。这样可以确认程序遇到非法输入时不是随便崩溃，而是按设计抛出指定异常。

这样设计的好处是测试比较清晰：正常功能、特殊输入、错误输入都覆盖到了，后面如果代码改坏了，也能通过测试快速发现问题。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65


package com.cold04.stringutils;

import org.junit.jupiter.api.AfterEach;
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Test;

import static org.junit.jupiter.api.Assertions.assertEquals;
import static org.junit.jupiter.api.Assertions.assertFalse;
import static org.junit.jupiter.api.Assertions.assertThrows;
import static org.junit.jupiter.api.Assertions.assertTrue;

public class StringUtilsTest {

 private StringUtils stringUtils;

 @BeforeEach
 public void setUp() {
 stringUtils = new StringUtils();
 System.out.println("初始化 StringUtils 对象");
 }

 @AfterEach
 public void tearDown() {
 System.out.println("StringUtils 测试方法执行完毕");
 }

 @Test
 public void testIsEmpty() {
 // 边界情况：null 和空字符串都属于“空”的特殊输入。
 assertTrue(stringUtils.isEmpty(null), "null 应该被判断为空");
 assertTrue(stringUtils.isEmpty(""), "空字符串应该被判断为空");
 // 正常情况：有内容的字符串不应该被判断为空。
 assertFalse(stringUtils.isEmpty("hello"), "非空字符串不应该被判断为空");
 }

 @Test
 public void testReverse() {
 // 正常情况：普通字符串应该按字符顺序反转。
 assertEquals("olleh", stringUtils.reverse("hello"), "hello 反转后应该是 olleh");
 // 边界情况：单字符和空字符串反转后都应该保持原样。
 assertEquals("a", stringUtils.reverse("a"), "单个字符反转后应该不变");
 assertEquals("", stringUtils.reverse(""), "空字符串反转后应该仍为空字符串");
 }

 @Test
 public void testReverseWithNull() {
 // 异常情况：reverse 不接受 null，应该抛出指定异常。
 IllegalArgumentException exception = assertThrows(IllegalArgumentException.class, () -> {
 stringUtils.reverse(null);
 }, "反转 null 应该抛出 IllegalArgumentException");

 assertEquals("字符串不能为 null", exception.getMessage());
 }

 @Test
 public void testConcat() {
 // 正常情况：两个普通字符串直接拼接。
 assertEquals("hello world", stringUtils.concat("hello ", "world"), "两个普通字符串应该正常拼接");
 // 边界情况：空字符串或 null 参与拼接时，不应该导致程序出错。
 assertEquals("hello", stringUtils.concat("hello", ""), "拼接空字符串应该保持原字符串");
 assertEquals("world", stringUtils.concat(null, "world"), "第一个参数为 null 时应按空字符串处理");
 assertEquals("hello", stringUtils.concat("hello", null), "第二个参数为 null 时应按空字符串处理");
 assertEquals("", stringUtils.concat(null, null), "两个参数都为 null 时应返回空字符串");
 }
}

运行测试

通过如下命令运行测试 StringUtils 模块，下图显示，相关测试很快便通过。

1

./mvnw -Dtest=StringUtilsTest test

总结

单元测试是现代软件开发中不可或缺的环节，它能在开发过程中早期发现问题、提高代码质量、减少时间，并为代码重构提供安全网。同时，相关的规范也能大大减少相关开发负担，增强系统稳定性。

通过这次 JUnit 单元测试实验，我不仅对 Java 中单元测试的基本写法和测试流程有了初步了解，也借这个机会快速熟悉了 Java 项目开发中的一些基础设施。例如，我了解了 Maven 这类依赖管理工具的作用，知道了如何通过 Spring Initializr 或命令行方式快速搭建 Spring Boot 项目脚手架，并在项目结构中区分业务代码和测试代码。

在单元测试方面，我学习并实践了 JUnit 中常见的测试注解和断言方法，例如 @Test、@BeforeEach、@AfterEach、assertEquals、assertThrows 等。通过计算器和字符串工具类的测试，我体会到单元测试不仅可以验证正常功能，也能覆盖边界情况和异常情况，从而帮助开发者更早发现问题、降低后续维护成本。

此外，由于我之前也写过 Python 中的 pytest 测试，对单元测试的基本思想并不陌生，例如测试函数的组织、断言结果是否符合预期、通过异常测试验证错误处理逻辑等。因此这次学习 JUnit 时，也能将它和之前使用 pytest 的经验联系起来理解。总体来看，这次实验让我对 Java 项目的搭建、依赖管理、脚手架生成以及单元测试流程都有了更完整的认识。

Cache 三种映射方式（直接/全相联/组相联）

Sat, 27 Dec 2025 10:00:00 +0800

基础知识（先把底层逻辑讲明白）

一、从“块”开始：Cache 是什么？为什么要映射？

如果你还不知道 Cache 是啥，可以把它理解成：

CPU 旁边的一小块“超快内存”（容量小但速度快）
主存（内存）很大但更慢

CPU 运行时会频繁读/写内存。为了避免每次都去“慢的主存”取数据，硬件会把最近用过、很可能马上还会用到的数据，先放进 Cache。

为什么 Cache 不是“按一个字节/一个字”搬运，而是“按块（Block）”搬运？

因为程序往往有 局部性（Locality）：

* **时间局部性**：刚用过的数据，可能马上还会用。
* **空间局部性**：访问了地址 A，往往很快也会访问 A 附近的地址。

所以 Cache 和主存交换数据时，通常一次把一整段连续地址搬上来，这段连续地址就叫一个 块（Block）。

举个最直观的例子：

块大小 = 16B
你读取地址 0x1000 的 1 个字节

硬件往往会把 0x1000 ~ 0x100F 这 16B 整块放进 Cache。这样你接下来再访问 0x1001、0x1002……就很可能直接命中（hit）。

“映射（Mapping）”到底在干嘛？

关键矛盾只有一句：Cache 容量远小于主存。

主存里有海量的块，但 Cache 里只有有限的“位置”能放块（这些位置叫 行 Line）。于是必须规定：

“主存的某个块，进 Cache 时允许放到哪些行（或哪些组 Set）里？”

这个规定就是 映射方式。

不同映射方式的区别，就体现在：

 - 允许放的位置越多：越不容易互相顶掉（冲突少），但查找/硬件更复杂。
 - 允许放的位置越少：查找更快/硬件更简单，但更容易冲突（两个热块老挤一个位置）。

这页只讲一件事：一段内存地址（或内存块）到底怎么“放进”Cache。

二、一次访问到底发生什么：Hit/Miss 机制

很多同学卡住不是因为公式，而是因为不知道“算出来的 Tag/Index 到底拿去干嘛”。下面给你一个能直接套题的流程。

Cache 一行（Line）里通常有什么

把一行想成一个小盒子，里面至少有：

Valid 位：这行里有没有装过有效数据（没装过就一定 miss）。
Tag：这行当前装的是“主存的哪一个块”。
Data（数据块）：真正的块内容。

可能还会有（看题目/课程深度，知道即可）：

Dirty 位：写回法（write-back）时用，表示这行数据是否被改过。
替换信息：比如 LRU 需要的“最近使用情况”。

一次读/写访问的标准流程（最重要）

不管直接映射/全相联/组相联，流程本质都一样，只是“要检查的行数”不同：

算块地址 BlockAddr：先把地址按块大小折算成“这是第几个块”。
根据映射方式定位候选位置：
- 直接映射：候选 = 1 行（算出 LineIndex）。
- 组相联：候选 = 1 组内的 k 行（算出 SetIndex）。
- 全相联：候选 = 全部行（没有 Index）。
命中判定（Valid + Tag 比较）：
- 如果某个候选行 Valid=1 且 Tag 匹配：Hit。
- 否则：Miss。
Hit 之后怎么取数据：用 Offset 在这行的 Data 里取到块内对应的字节/字。
Miss 之后会发生什么（装入/替换）：
- 从主存把“目标块”取到 Cache。
- 若候选位置有空行：直接放进去。
- 若没有空行：按替换策略（LRU/FIFO/随机）选一个受害者（victim）顶掉。
- 若采用写回法且 victim 的 Dirty=1：先把 victim 写回主存，再覆盖。

一张“从地址到命中/缺失”的流程图（ASCII 版）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26


CPU 发起一次访存（给你一个地址 Addr）
 |
 v
 按块大小切：BlockAddr = floor(Addr / BlockSize)
 |
 v
 按映射方式定位候选位置（行/组）：
 - 直接映射：LineIndex = BlockAddr mod NumLines
 - 组相联： SetIndex = BlockAddr mod NumSets（组内 k 路都要查）
 - 全相联： 候选 = 全部行
 |
 v
 在候选行里做命中判定：
 若存在某行：Valid=1 且 Tag 匹配 ---> HIT
 否则 ---> MISS
 | |
 | v
 | 选空行或按替换策略挑 victim
 | |
 | (若 write-back 且 victim Dirty=1 则先写回)
 | |
 | v
 | 从主存取目标块，装入 Cache
 | |
 v v
 用 Offset 取块内数据/完成读写 重新访问（这次通常会 hit）

写策略（题目不考细节也能看懂）

写操作常见两对策略（题目若没说，通常只考映射/命中率，写策略可忽略）：

Write-through（写直达）：写 Cache 同时写主存（简单但慢）。
Write-back（写回）：先只写 Cache，换出时再写回（快但要 Dirty 位）。
Write-allocate（写分配）：写 miss 也把块先装入 Cache 再写（常见）。
No-write-allocate：写 miss 不装入 Cache，直接写主存（某些场景用）。

三、术语对齐：块（Block）/ 行（Line）/ 组（Set）

块（Block）：Cache 和主存交换数据的最小单位。题目常给“块大小 = 4 字 / 16B”等。
行（Line）：Cache 里存放一个块的位置。有时也叫“Cache 块”。
组（Set）：组相联里的一组“行”。例如 2 路组相联 = 每组 2 行。

你只要记住：

直接映射：每个主存块只能去 Cache 的“唯一一行”。
全相联：每个主存块可以去 Cache 的“任意一行”。
组相联：每个主存块只能去“唯一一组”，但在组里可以去“任意一行”。

四、三种映射方式总览（先建立直觉）

方式	主存块能放到哪里	查找速度	硬件成本	常见缺失类型
直接映射 (Direct Mapped)	固定 1 行	最快	最低	冲突缺失明显
全相联 (Fully Associative)	任意行	最慢	最高	基本无冲突缺失
组相联 (Set Associative)	固定 1 组 + 组内任意行	居中	居中	冲突缺失缓解

缺失（Miss）通常分三类（考试高频）：

强制缺失（Compulsory/Cold Miss）：第一次访问某块必 miss。
容量缺失（Capacity Miss）：Cache 总容量不够，装不下要用的块。
冲突缺失（Conflict Miss）：容量够，但“映射规则”把多个块挤到同一行/同一组。

五、地址怎么切：Tag / Index / Offset

题目常写：

$$ \text{Address} = \text{Tag} \parallel \text{Index} \parallel \text{Offset} $$

含义（按字节寻址的经典默认）：

Offset（块内偏移）：你要这个块里的第几个字节/字。
Index（索引）：去 Cache 的哪一行（直接映射）/哪一组（组相联）。
Tag（标记）：用来确认“这一行/这一组里装的到底是哪一个主存块”。

三种映射方式（核心）

块地址（Block Address）：
$$ \text{BlockAddr} = \left\lfloor \frac{\text{MemAddr}}{\text{BlockSize}} \right\rfloor $$
直接映射：
$$ \text{LineIndex} = \text{BlockAddr} \bmod \text{NumLines} $$
$k$ 路组相联（$k$-way）：
$$ \text{SetIndex} = \text{BlockAddr} \bmod \text{NumSets},\quad \text{NumSets}=\frac{\text{NumLines}}{k} $$

小提示：如果题目给的访问序列看起来像 16,17,18,19 ... 这种“连续加 1”，很可能给的是字地址或字节地址；你要先用块大小把它们折算成块地址（上面的 BlockAddr）。

一、直接映射（Direct Mapped）

规则（一句话版）

每个主存块只能映射到 Cache 的唯一一行：

$$ \text{LineIndex} = \text{BlockAddr} \bmod \text{NumLines} $$

做题时你在做什么

先算这个访问属于哪个 BlockAddr。
再用取模算出它去 哪一行。
去那一行比对 Tag：
- Tag 相同：命中（Hit）
- Tag 不同或空：缺失（Miss），把新块塞进来（旧的被直接踢掉）。

直观图

二、全相联（Fully Associative）

规则（一句话版）

主存块可以进 Cache 的任意一行，所以 没有 Index（或 Index 长度为 0）。

做题时你需要注意什么

命中判定：要在“所有行”里找 Tag（硬件用并行比较，题目里就理解为“全表查”）。
缺失时：必须有 替换策略（LRU/FIFO/随机）。题目不说通常默认随机或 LRU（看老师口径）。

直观图

三、组相联（Set Associative）

规则（一句话版）

主存块只能去唯一一组，但可以放到组内任意一路（way）：

$$ \text{SetIndex} = \text{BlockAddr} \bmod \text{NumSets} $$

2 路组相联：你脑中应该出现的画面

Cache 被分成很多组（Set）。
每组里有 2 行（2 way）。
来了一个块：先用取模找到组号；再在这组里两行都比 Tag。

直观图

题目与练习（把分数拿到手）

一、一个极小例子把三种方式“算通”

假设（为了演示简单）：

Cache 一共 4 行
块大小 = 1（忽略 Offset）
访问的块序列：0, 4, 0, 4

直接映射（4 行）

LineIndex = BlockAddr mod 4
0 和 4 都映射到行 0
结果：0 miss，4 miss（顶掉 0），0 miss（顶掉 4），4 miss
全是 miss：典型的冲突缺失

全相联（4 行）

0、4 都能进任意行
结果：0 miss，4 miss，0 hit，4 hit

2 路组相联（4 行 = 2 组 × 2 路）

NumSets=2，SetIndex=BlockAddr mod 2
0 和 4 都落到组 0，但组 0 有 2 路
结果：0 miss，4 miss（组0 还装得下），0 hit，4 hit

二、题目分析

Cache：2 路组相联

Cache 总行数：32 行（块）

块大小：4 字（word）

地址位宽：16 位（本题命中率计算不一定用到位宽）

访存序列（看起来是“字地址”）： 16 17 18 19 144 145 146 147 252 253 465 466

第一步：把“地址”先变成“块地址 BlockAddr”

块大小是 4 字，所以每 4 个连续字地址属于同一个块：

$$ \text{BlockAddr} = \left\lfloor \frac{\text{WordAddr}}{4} \right\rfloor $$

把序列换成块地址：

16~19 都在块 $\lfloor 16/4 \rfloor = 4$
144~147 都在块 $\lfloor 144/4 \rfloor = 36$
252~253 都在块 $\lfloor 252/4 \rfloor = 63$
465~466 都在块 $\lfloor 465/4 \rfloor = 116$

所以块序列是：

4,4,4,4, 36,36,36,36, 63,63, 116,116

第二步：算组号（2 路组相联）

总行数 32，2 路 $\Rightarrow$ 组数：
$$ \text{NumSets} = 32/2 = 16 $$
组号：
$$ \text{SetIndex} = \text{BlockAddr} \bmod 16 $$

计算：

块 4：$4\bmod 16=4$（组 4）
块 36：$36\bmod 16=4$（组 4）
块 63：$63\bmod 16=15$（组 15）
块 116：$116\bmod 16=4$（组 4）

注意：4、36、116 三个块都挤在同一组（组 4），这就是本题的“冲突热点”。

第三步：按替换策略判 Hit/Miss（假设初始 Cache 为空，组内 LRU）

访问块 4：miss（把块 4 装入组 4）
再访问块 4 三次：hit、hit、hit（同一块内连续访问，体现空间局部性）
访问块 36：miss（组 4 还有空位，装入）
再访问块 36 三次：hit、hit、hit
访问块 63：miss（装入组 15）
再访问块 63 一次：hit
访问块 116：miss（组 4 满了，需要替换；LRU 会踢掉“更久没用”的块 4）
再访问块 116 一次：hit

统计：

总访问：12 次
miss：4 次（第一次见到块 4 / 36 / 63 / 116）
hit：8 次

命中率：

$$ \text{HitRate} = \frac{8}{12} = \frac{2}{3} \approx 66.7\% $$

这题在考你什么

块大小带来的空间局部性：16~19 一次装块后后面 3 次都 hit。
组相联缓解冲突：虽然 4、36、116 都落同一组，但 2 路能同时容纳其中两个。
替换策略影响细节：如果后续又访问块 4，就会因为刚才被踢掉而 miss。

三、举一反一（一个正例 + 一个反例）

正例：先“算块地址”再“算组号/行号”

题设：块大小 4 字，访问字地址 145。

块地址：$\lfloor 145/4 \rfloor = 36$
2 路组相联，32 行 $\Rightarrow$ 16 组
组号：$36\bmod 16=4$

结论：它一定在组 4（组内哪一路要看替换策略与当前内容）。

反例：把“字地址”当成“块地址”直接取模（常见低级错）

错误做法：直接拿 145 mod 16 = 1，说它在组 1。

为什么错？

因为 Cache 映射是按“块”为单位的。
145 是块内的一个字地址，它属于块 36；映射应该用 36 去取模，而不是用 145。

iPhone SE3 上手体验，续航和便携的碰撞

Sat, 06 Sep 2025 15:00:00 +0800

前言

用腻了Android手机，总想逃回苹果生态。虽然Android自由安装应用的特性异常好用，但各家品牌各自为政，所谓“碎片化”严重，有时候统一的体验反而更重要。

你问为什么要选择iPhone SE3？的确，性价比对我来说是首位的，类似865的性能对我来说完全够用，毕竟我最多算轻度游戏玩家。那最劝退的呢？显然是捉襟见肘的续航了。

用机偏好

在选择手机的时候，最重要的还是需要考虑好自己的用机需求和相关的偏好。对于我来说，很方便的就可以观察到，我在使用手机的时候，娱乐和即时通讯是耗电的大头，而其他的需求，例如扫码使用小程序，购物，生活，打车等生活服务类的应用，使用频率并不高。但如果观察存储占用，前者的占用反而并不高，反而是后者占用的存储空间更大。可以总的概括为，装80%的应用，完成20%的事。

为什么选择iPhone SE3

如果你要问大部分人为什么选择，可能会告诉你：“因为便宜啊！”但对我来说。确实是这样的，但也不完全是。要便宜的话，安卓阵营的选择更多，但我更看重apple生态带来的便利体验。此外，我还有一台小米10，作为那个”装20%应用”的手机，这样一来，我只需要一台无修改的设备来完成大部分的轻度应用即可。综合来看，我在iPhone 13 mini和iPhone SE3之间犹豫了很久，最终选择了iPhone SE3。

使用体验

拿到手上的第一感觉就是轻巧，现在的手机普遍又大又重，拿起这么小的手机，一下子手部的负担小了很多。单手操作也很轻松，甚至可以用大拇指完成大部分的操作。

对于这个16:9的屏幕比例，看惯了那么多全面屏，对我来说看回来也并不会觉得有什么不适应，反而觉得很舒服。但在2025年的今天，开发者在开发应用的时候可能并不会考虑16:9屏幕的显示效果，毕竟从iPhone X发布到现在已经7年过去了，16:9的屏幕比例已经很少见了。好在大部分应用都能适配，偶尔会遇到一些应用界面显示不全的情况，适配不全的情况一般来源于跨平台开发的应用，但好在于暂时没有遇到影响使用的情况。

续航方面，确实是iPhone SE3的短板，毕竟电池容量摆在那里。但好在我对手机的使用并不重度，一般都能在手机电量不足时及时给手机“续命”。对于这么小的手机来说，用一个20w的充电器就足够了，充电速度也很快。

拍照

虽然说SE3的摄像头并不出色，但对于拍摄文档和扫码、随手拍来说是完全够用的。对于这个摄像头，我最满意的反而是文档拍摄的清晰度。现在部分手机（如小米10）在拍摄文档的时候，边缘可能会有发虚的情况，而iPhone SE3则不会出现这种情况，拍摄的文档清晰度很高。

eSIM

值得一提的是，这台手机的外版是支持eSIM的，那就很方便的，可以将我用于接受验证码的eSIM放在上面，收到短信的时候可以一键填充，十分方便。

总结

总的来说，iPhone SE3是一款非常适合轻度用户的手机，尤其是对于那些需要一台便携、轻巧且能够满足日常使用需求的用户来说，iPhone SE3无疑是一个不错的选择。虽然续航是它的短板，但对于我这样的使用习惯来说，完全可以接受。但如果你问我是否推荐，其实我并不会。这台手机其实只适合作为大部分人的“备用机”，甚至连备用机都不能上榜。续航是他的短板，但在其他方面，其实这是一台很均衡的，来源于旧时代的旗舰手机。即时他有现代化的A15处理器，现代化的eSIM功能，但他渐渐的也和这个时代格格不入了。

购入新域名，现在可以更畅快的访问我的主页!

Sun, 22 Dec 2024 14:34:48 +0000

今天临时起意，遂购买co1d.in。

当初准备在namesilo购买，不过一比价，发现Spaceship更便宜，遂换这家服务商。

因此，现已可通过:

co1d.in 访问我的主页
b.co1d.in 访问我的博客
n.co1d.in 访问我的笔记

Blog翻新，更优雅的界面，更舒适的工作方式

Mon, 29 Apr 2024 09:00:00 +0800

前段时间正在愉快的对电脑进行维护，但一不小心手滑敲错了命令，导致我用了两年的Windows系统盘被无意清空。因为之前有备份文件的习惯，所以对我的损失并不算大。但由于Blog的源文件存储在家里的机械盘中，找回不那么方便，加上感觉之前的主题有些较旧了，索性打算好好的重建一下Blog。

搜寻适合自己的静态网站生成器

开始的时候，我仍打算使用Hexo作为博客的生成器，于是考虑搜寻一个好看且较贴切个人风格的主题。但无意中看到了 Hugo，便本着尝鲜的想法，打开的Hugo的官网进行查看。于是第一步，就开始挑选主题。说起来可能有那么些不可思议，我第一眼便相中了 Hugo Theme Stack 这个主题，设计风格简单明了，也没有多余的元素，而且更好的是，他可以直接使用 Hugo Theme Stack Starter 导入自己的Github仓库，并可以借助 Github Action 进行自动编译文章。这样一来，确实可以简化不少的工作流程，方便我随时随地使用CodeSpace更新文章。就好比这篇文章，我就使用Surface远程CodeSpace进行编辑的。

配置网站和熟悉逻辑

这部分其实没那么多好说的，我就是按照自己的风格进行调试，你可以在Github Commits里面看到我相关操作，因此没那么多可以聊的，按照帮助配置就好。

迁移文章和遇到的问题

网站按照自己的想法配置好后，就到了迁移文章的时候。前面说过，因为源文件丢失了，所以网站内容我都是直接从老Blog 复制粘贴下来的。因为前面的文章没有引用图片，所以开始并没有注意到问题，直到我开始迁移《记一次数据恢复和数据冷备份》这篇文章的时候，才发现通过外链引用的图片居然打不开（心想，wtf，难道这个框架不支持图片的预览嘛），开始以为是配置没有开导致的，直到我开始看官方文档，直到我注意到

1
2
3
4
5


WARNING

Inserting external images is supported, but it is not recommended.

Features like image gallery and image zooming will not work with external images. Those feature needs to know the image's dimensions, which is not possible with external images.

啊？我当时注意到这个的时候还挺震惊的，因为我的习惯就是从外链引用图片，这下子确实麻烦起来了,甚至让我有了放弃使用的想法。不过好在经过简单搜索，发现了 Hugo Theme Stack图库是怎么工作的？怎样才能支持外链图片？这篇文章。

不过即使找到了解决方案，也没法修改。显而易见的是，我的仓库里并没有layouts文件夹，更别谈去修改了。我又开始打起了退堂鼓，不过之后又进行了一番搜索，发现官方的仓库中也说明了这一情况，但没说明白。通过Hugo Modules 方式加载，可以通过新建这个目录，本地的文件会自动覆盖编译时加载的文件。这个设计太赞了！于是，按照解决方案修改好之后，在config.toml中按照规则关闭imageProcessing.content改成false并添加有关项目，再次测试发现外链图片可正常查看了。

Hugo的优势

用一个字形容就是"快"，而且并不需要像node.js那样在每次安装依赖时都弄得很复杂。这个主题支持使用Github Action编译，也使得我在每次写完之后可以只管上传就行，流程方面也能更快了。总而言之，这个工作流让我很满意。下一步来说，我应该会考虑专注于创作点优质的Blog内容，而系统化的内容仍会在酷丁的笔记中持续更新。

记一次数据恢复和数据冷备份

Mon, 29 Jan 2024 09:00:00 +0800

前言

最初，家里的一些老照片和老的资料是放在老电脑的硬盘中。不巧的是，老电脑的硬盘可能是被误格式化，导致资料丢失。刚放假的时候，出于想尝试的目的，以及想要找回一些资料的目的，我尝试了一下数据恢复，自此开始，我开始构建自己的资料冷备份体系。

首先说明，我对资料的备份和恢复懂的并不多，这里记录的方法可能是错的或者并不是最适合你的方法，只是希望记录下来，以便以后查阅。欢迎各位大佬指正。

数据恢复

因为数据之前有部分被覆写，加上硬盘也被重新格式化了，因此，我选择使用DiskGenius恢复数据，最终，我成功找到了不少资料和一些照片。但因为数据部分被覆盖，很多照片都丢失了。由此可见，数据无价并不是闹着玩的。

当时我操作的方法也很土，使用Ventoy启动了我移动硬盘中的Win to go系统，然后在Win to go系统中安装了DiskGenius，最后使用DiskGenius恢复数据。这种方法的好处是不用拆机，但因为在老电脑上运行，速度显然受到了老电脑机能的限制。不过经过一个下午的时间，经过筛选后，也找到了不少资料。

从DiskGenius中恢复的资料，我将其放在了移动硬盘中，但这些资料没有文件名，需要手动整理。为了不让自己太累，我直接让Copilot辅助我写了一个小程序，来用于将word文档中的标题作为文件名。这样，我就可以直接通过文件名来找到我想要的资料了。

同样，表格文件也借助了差不错的方法解决。自此，资料初步整理完成。

冷备份老资料

显然，放在我的移动硬盘中以及电脑中也不是长久之际，我有定期清理空间的习惯。另外，移动硬盘存在丢失的风险。在网上浏览一圈之后，看到了“冷备份”这个词。由此，我开始挑选备份介质。

挑选介质

首先必须明确一点，目前因为预算方面问题，我的预算并不太够。幸运的是，目前来说，我需要冷备份的资料并不是很多，也并不需要太大的储存空间。不过考虑到介质可能很久才打开检查一次，我根据需要选择机械硬盘。

可能去看大部分博主的推荐，都会告诉你，目前4TB以下的机械硬盘都不那么推荐。不过考虑到预算和上述的实际需求，经过多方面学习，最终选择了2块全新的西数的1TB紫盘来完成我的任务。

读取硬盘，目前我选用的是绿联的硬盘盒。建议替换自带的电源，但我目前预算不足，没有替换。

拷贝资料

我没有组Raid的条件，故我选择手动“镜像”两个盘的文件。我先拆封了一个盘，在电脑上整理好所有资料，使用fastcopy将资料复制到硬盘目录。使用fastcopy纯粹是因为他可以在拷贝资料的时候校验，拷贝大文件的时候也相对较快，体验较好。

在弹出硬盘时，注意先在电脑上选择弹出，等待数秒保证硬盘停转和磁头归位后，关闭硬盘盒电源并拔出硬盘。这样做，一方面可以防止硬盘还在读写，另一方面，磁头离开硬盘盘面后，可以防止移动时磁头划伤硬盘，变成“唱片机”。

定期查看和写入资料

一般来说，每个阶段之后，都需要将一些资料进行备份。我建议周期是半年到一年定期检查下。当然，有重要资料的时候，也别忘记写入，时间有限的话，也可以一同检查下硬盘的smart值。

对于用于备份的机械硬盘来说，smart值还挺重要的，有时候smart出现警告后，要及时考虑转移资料和选择新硬盘进行备份。

总结

对于每个人来说，都有或多或少的重要资料。永远要记住：“数据无价”。定期做好数据备份是一项不错的选择，不要等到失去了再追悔莫及。

这里有个小插曲，我在3月份的时候，无意中格式化了Windows系统盘。因为备份习惯，导致我的资料和进度丢失并不算太多，所以还是那句话，数据无价，勤备份才是王。

解决mysql_secure_installation ERROR 2002

Tue, 21 Nov 2023 21:00:00 +0800

问题描述

在使用mysql_secure_installation命令时，出现以下错误：

1

ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (2 "No such file or directory")

问题分析

显而易见的是，1mysql_secure_installation1命令无法连接到本地的MySQL服务，原因是MySQL服务没有启动。

但在之前的操作步骤中，已经使用了systemctl start mariadb命令启动了MySQL服务，为什么还是无法连接呢？

进入目录查看可知，在此目录下无/var/lib/mysql/mysql.sock文件。

使用 find / -name 'mysql.sock' 命令查找，发现文件在/tmp/mysql.sock（部分在/tmp/sys…/tmp/mysql.sock 之下）。

解决方法

先使用 find / -name 'mysql.sock' 命令查找mysql.sock文件，找到文件所在目录。

复制这个目录，为其创建软链接，如下：

1

ln -s /tmp/sys.../tmp/mysql.sock（这里写的是你复制的目录） /var/lib/mysql/mysql.sock

再次尝试使用mysql_secure_installation命令，问题解决。

多说两句

其实，在新版的Mysql/MariaDB中，修改密码的方式有所变更，使用mysql_secure_installation命令修改密码的方式已经不再适用。具体可以看这里

新版初始化可以考虑手动初始化:

1
2
3
4


mysql(如果之前有密码则加上有关内容)
ALTER USER 'root'@'localhost' IDENTIFIED BY '新密码';
flush privileges;
exit;

配置ProxyChains，使得终端可以使用代理

Mon, 30 Oct 2023 22:00:00 +0800

兄弟这两天忽然找我，他们实验室服务器因为配置原因，无法直接访问外网，但是他们需要下载一些东西，于是就想到了使用代理。因为一台机器中存在多个用户，自然不能在系统中直接配置代理，经过一翻查找，就想到了使用proxychains。

基本环境

简介也说明了，因为实验室的服务器提供给多人使用，部分用户是没有管理员权限的（避免因此造成不必要的麻烦），所以不能在系统中直接配置代理，这样一方面是对路由资源会造成损耗，另一方面，也不太方便在代理和直连之间切换。所以，使用proxychains是一个不错的选择。

安装proxychains

因为实验室服务器使用的是Debian，所以使用apt安装即可。

1

sudo apt install proxychains

配置proxychains

一般来说，proxychains的配置文件在/etc/proxychains.conf，但是我们强调，因为上述特殊环境，我们需要在不同用户下使用不同的配置，所以我们需要在用户目录下创建配置文件，这样就可以实现不同用户使用不同的配置。

1

vim ~/.proxychains/proxychains.conf

在这个配置文件中，我们需添加以下内容:

1
2


[ProxyList]
socks5 127.0.0.1 1080 username password

其中，username和password是你的代理服务器的用户名和密码，如果没有，可以不填写。服务器地址和端口可按照需求修改。

使用proxychains

使用proxychains很简单，只需要在命令前加上proxychains即可，例如:

1

proxychains git clone https://github.com/Coldin04/NoteShare.git

或者，也有另外一种方式：proxychains bash

这样，就可以在一个新的bash中使用代理了。

测试连通性：

注意：如果使用的是socks5代理，因为socks5代理处于第五层，所以ping命令是无法使用的，只能使用curl或者wget等命令。 proxychains curl cip.cc

参考资料

[1] proxychains-ng
[2] Linux 配置 ProxyChains 本地代理

新站上线！用Vuepress搭建的个人笔记库

Mon, 30 Oct 2023 22:00:00 +0800

自从转到计算机专业之后，因为很多命令在电脑上执行，故开始尝试使用了Obsidian记录笔记。一个学期下来，也攒了不少内容。本着分享的精神，我最初的想法是将Obsidian仓库发布，也方便对笔记进行备份。后来发现，Obsidian的第三方发布服务均有一定的缺陷，而官方发布服务又需要付费，价格又不太理想，很长一段时间都放弃去做这个事情了。

后来，在看到一些文档的的时候，发现了很多人都使用这一套“风格”进行搭建，如小林Coding 、ArchLinux简明指南等。发现均以Vuepress为基础进行搭建，于是我也开始尝试使用Vuepress搭建自己的笔记库。（其实之前考虑过Notion等工具，但后来放弃）

Vuepress

VuePress 由两部分组成：第一部分是一个极简静态网站生成器 (opens new window)，它包含由 Vue 驱动的主题系统和插件 API，另一个部分是为书写技术文档而优化的默认主题，它的诞生初衷是为了支持 Vue 及其子项目的文档需求。

更多可以看官方文档。

搭建过程

小插曲

其实，Vuepress的安装非常简单，只需要使用yarn即可:

1
2
3


mkdir vuepress-starter && cd vuepress-starter
yarn init
yarn add -D vuepress

当然，也别急着就开始了，想让网站更丰富，可以考虑安装第三方的主题。当然，如果想要了解更多安装和配置的细节，也可以进入官方文档了解更多细节。

我使用的是vuepress-theme-hope 这个主题，这个主题主题很大程度上继承了 VuePress 默认主题的配置，并在此基础上添加了大量功能与布局优化。而且，这个主题也有blog功能，有兴趣的话可以了解一下。

标题说这是小插曲，那也就顺便聊聊。当时我拿到手，也是一股脑的按照上面的步骤安装了Vuepress，顺便熟悉了一下基本配置。我有个小习惯，当我正在研究的或者正在学习的东西（前提是感兴趣），我会去B站搜索看看别人的视频，或者去搜索引擎上以这个名称为关键词看看别人的配置过程这样的。无意就发现了Vuepress-theme-hope和Vuepress-theme-repo这两个主题。

当我点开了这两者的搜索条目，才发现这两个主题并非像Wordpress或者Hexo那样导入进去，或者放入一个文件夹就能用，而是单独通过包管理器（pnpm或yarn）进行新建。后来，我含泪去转移了已经整理完成的笔记，不过这些的工作量也并不大就是。

正式开始

安装

建议参考：小白教程首先，保证安装了Node.js、yarn\Pnpm和VS Code（或其他编辑器），然后根据提示安装即可。

但我既然在这里提到这件事，说明我也遇到了一些问题，这里也顺便记录一下。

在运行时，我首先遇到了这样的错误：

1
2
3


Error [ERR_MODULE_NOT_FOUND]: Cannot find package 'katex' imported from /home/coldin04/Documents/webnote/docs/node_modules/@mdit/plugin-katex/lib/index.mjs
 at new NodeError (node:internal/errors:406:5)
 ......

这个错误的原因是因为vuepress-theme-hope的依赖包katex没有找到，查询后发现，可通过:yarn add katex解决。

tips:
之后查询到，这个依赖包是用于数学公式的，如果不需要，可以不安装，去配置中将其注释掉即可。

然后，我又遇到了这样的错误：

1
2
3
4


Error: Cannot find module 'reveal.js/dist/reveal.css'
Require stack:
- /home/coldin04/Documents/xxx/@mr-hope/vuepress-plugin-pwa/lib/client.js
 .....

这个错误的原因是因为vuepress-theme-hope的依赖包reveal.js没有找到，查询后发现，可通过:yarn add reveal.js解决。

此时，如果执行yarn dev，若能够正常运行，则即可进行下一步进行仔细的配置了。当然，如果还有别的运行问题，也可以借助搜索引擎或类似于ChatGPT语言大模型进行解决。

配置

因为Vuepress也配置过好几天了，具体也无法记的很详细了，这里就简单的说一下。当然，每个人的风格不同，配置是自然不同的，我的操作更多的是提供思路，请不要被我的步骤局限住了。

base

首当其冲的是配置这个选项，可参考Base。这个选项是用于设置网站的基础路径，如果你准备发布到 https://.github.io// ，也就是说你的仓库地址是 https://github.com// ，则将 base 设置为 “//“。

导航栏

这个选项是用于设置导航栏的.

显而易见的是，我的导航栏并没有什么特殊的设置，只是简单把写过的笔记进行分类整理，然后放在了导航栏中。

侧边栏

对于侧边栏，我是选择了通过文件结构生成，毕竟因为是笔记站，这样配置起来，可以更方便的去查找笔记。不过随着之后内容的增多，也可能会考虑对不同笔记目录单独生成不同的侧边栏。

~~主要是因为懒~~ ，我选择直接将相关配置注释，关闭评论区，之后可能会考虑使用第三方评论系统。

SEO

这个主题的一大优点，便是自带SEO功能，且默认是开启的，可参考SEO。

对于其他功能，我也并没有去仔细关注，毕竟这个主题的配置项还是很多的，而且也不是每个人都需要的，对于笔记站来说，我觉得这些功能也并不是很重要，在之后的使用中，如果有需要，再去配置也不迟。

结语

这个笔记站的搭建，也是我第一次使用Vuepress，也是第一次使用Vue，所以在搭建过程中，也遇到了很多问题，也是在解决问题的过程中，学习了很多知识。在这里，也希望能够帮助到其他人，也希望能够帮助到自己。

在这次的配置过程中，确实让我整个人都得到了一个放松。前段时间状态确实不太行。在这次配置的过程中不断面对问题，解决问题，让我感到了久违的满足感和获得感。也让我重新找回了学习的乐趣。

感谢vuepress、vuepress-theme-hope等开源项目的开发者，感谢他们的付出，让我能够使用这么好的工具。最后，也感谢你能够看到这里，希望你能够喜欢这个笔记站。