Exyone Blog

用 Eleventy 打造一个三栏博客：从零搭建到多平台自动部署

2026-06-15T00:00:00Z

之前我的个人博客用的是 Jekyll + Chirpy 主题，走了本地构建再推送的路，省去了平台构建不一致的麻烦。但那套方案有个绕不过去的限制：Chirpy 主题打包在 Ruby gem 里，能改的只有配置文件和有限的几个 include。如果你想动布局、改色调、换字体——这些在 Chirpy 的体系里都不是"改一行配置"能解决的事。Jekyll 本身又绑定在 Ruby 生态里，插件写起来说实话也不算顺手。

搬到 Eleventy 的理由很简单：它不绑定任何模板语言，不绑定任何 CSS 方法论，连输出格式都不绑定。你想要什么自己搭。副作用是，一切都要自己搭。但正是这种"自己搭"的模式，让 11ty 成了最接近裸写 HTML 的静态站点生成器。你在模板里写什么标签，它就输出什么——不会在你不知情的时候往页面里塞多余的 div、inline script 或 CSS class。这对于一个想精确控制每一行输出的开发者来说，是无可替代的体验。我希望这种对输出的克制，也能通过最终的页面传达给读者。

结构三层：数据、逻辑、表现

我把整个项目划分成三个层次。最底层是数据层，src/_data/ 目录下放着一堆 JSON 和 JS 文件。site.json 定义站点名称、时区、每页文章数等全局参数；author.json 存个人信息和社交链接；comments.json 保存 Giscus 和 Twikoo 的配置；taxonomy.js 做中文字段到 URL-safe slug 的映射。还有两个计算数据文件，sidebarCategories.js 和 sidebarTags.js，它们在构建时扫描所有文章，统计分类和标签的频率，输出给右侧栏使用。

中间是逻辑层，一个 .eleventy.js 文件处理所有构建逻辑。包括插件的注册（RSS 生成、代码高亮）、过滤器（日期格式化、阅读时间估算、HTML 剥离、分页导航的 prev/next 计算）、集合的定义（文章按日期排序、分类聚合、标签聚合），以及最重要的搜索索引生成。

搜索索引是一个特殊的集合——searchIndex。它不在模板中渲染成页面，而是在构建时遍历所有文章，读取每个 Markdown 文件，剥离掉 YAML frontmatter，再清除 HTML 标签和 Markdown 标记，截取前 1500 个字符，最后输出成一个 search.json 供客户端使用。这样做的好处是搜索索引在构建时就确定了，用户打开搜索时只需要下载一个预先生成的 JSON 文件，不需要在服务端跑任何查询。

最上层是表现层。布局模板在 src/_layouts/ 下，页面路由在 src/routes/ 下，组件在 src/_includes/ 下。CSS 全部分散在 src/assets/css/ 下的五个文件里：variables.css 存放所有设计变量（颜色、字体、间距、阴影、圆角）、base.css 做 CSS reset 和排版基调、layout.css 定义三栏网格和页面结构、components.css 覆盖所有组件样式（卡片、徽章、分页、侧边栏、搜索弹窗、文章导航、TOC 等）、theme.css 做表面装饰（噪点纹理、悬浮效果、入场动画、回到顶部按钮）。responsive.css 专门处理响应式断点。

没有用任何 CSS 框架。Bootstrap、Tailwind、Bulma——都没有。每一个像素都是手写的 CSS 自定义属性。

三栏的取舍

左侧栏是固定的 240 像素，包含作者卡片、导航菜单、一个每秒更新的数字时钟，还有一个 JavaScript 生成的当月日历。右侧栏是固定的 260 像素，包含自动生成的目录、站点统计、分类列表和标签云。中间的主内容区自适应填满剩余空间。

这个布局在桌面端表现不错，但在平板上我切成了两栏：隐藏右侧栏，左侧栏保持固定。手机上则完全放弃侧栏，左侧栏变成一个从左侧滑出的抽屉式菜单，由汉堡按钮控制开关。响应的断点选在 1200px 和 768px——前者是常见笔记本屏幕的宽度下限，后者是 iPad 竖屏和手机的分界线。

颜色的设计上，浅色模式以柔钢蓝为主色调（#5a8fb4），配以暖灰色背景（#e0e8f0）和白色卡片（#ffffff）；暗色模式则切换到暖琥珀色（#e8915a），背景用深灰（#18181b），卡片用略浅的深灰（#222225）。四个辅助色分布在不同的 UI 元素上——分类标签用墨绿系，标签云用暖棕系，侧栏装饰用薰衣草系，代码块用土橘系。用户切换一次主题后，选择会被存进 localStorage，下次打开页面直接复用，不依赖系统偏好。

细节上，所有圆角都设成了 0。这是有意的选择——直角在中文排版里比圆角更接近传统印刷的质感，尤其是配合衬线字体做标题时，直角边框和规整的网格更能呼应纸媒的气质。

搜索和脚本

搜索功能用了 Fuse.js 做客户端模糊匹配。构建时先生成一个 search.json，结构是一个数组，每篇文章包含标题、URL、日期、摘要、标签、分类，以及截取过的正文前 1500 个字符。用户在搜索弹窗里输入关键词后，Fuse.js 在浏览器端做模糊匹配，权重分配是标题 50%、摘要 25%、正文 15%、标签和分类各 5%。阈值为 0.35，允许单字符匹配——这对中文搜索很重要，因为中文不像英文那样有天然的空格分词。

用户的搜索偏好历史记录存进来了，每次按 Ctrl+K 或点击搜索图标，弹窗显示的输入框自动获得焦点，搜索结果实时刷新。

JavaScript 文件全部手写，没有用 jQuery 或其他框架。主要功能包括：左侧栏移动端抽屉的开闭、返回顶部按钮的显隐（滚动超过 300px 时出现）、阅读进度条（根据 scrollY 与可滚动总高度的比值更新宽度）、标题锚点链接（为文章内容中每个标题生成一个可点击的链式图标，点击后复制完整 URL 到剪贴板）、目录生成（从 h2/h3 提取标题文本构建 TOC 列表，滚动时自动高亮当前章节）、主题切换、数字时钟（每秒更新）、当月日历（JavaScript 渲染，支持前后翻月）、以及搜索弹窗的全部交互逻辑。

Service Worker 在生产环境下注册，用来预缓存站点资源，实现离线访问能力。manifest.json 中定义了 PWA 的基本配置，包括启动画面、主题色和应用名称。

部署和 CI/CD

代码推送到 GitHub 后，GitHub Actions 自动执行部署流程。先把 _site 目录上传为 GitHub Pages 的 artifact，然后调用官方的 deploy-pages action 部署到 GitHub Pages。同时我配置了两个额外的推送目标：一个是推送到 GitLab 做镜像仓库，另一个是克隆 Codeberg Pages 仓库，把 _site 内容复制进去，写入自定义域名文件，再推送回 Codeberg。三个平台共用同一份构建产物，确保输出完全一致。

Build.ps1 是 Windows 下的构建脚本，逻辑很简单：删除旧的 _site 目录，然后执行 npx @11ty/eleventy。

模板和数据流

所有的文章使用同一个 frontmatter 结构。_posts.json 为 _posts/ 目录下的所有 Markdown 文件设置默认值：布局为 post.njk，永久链接格式为 /posts/building-eleventy-blog-system/。每篇文章的 frontmatter 至少包含标题、日期、分类和标签。摘要是可选的，如果不填，首页卡片上会显示正文的前几行。

评论系统同时支持 Giscus 和 Twikoo。comments.json 中配置了两个 provider 的参数，post 布局底部的 comments.njk 组件根据 provider 字段选择渲染 Giscus 的 client.js 脚本还是 Twikoo 的初始化脚本。两个评论系统可以同时启用，读者自由选择。

路由方面，除了文章详情页，系统还生成了首页分页列表、分类索引页、分类详情页、标签索引页、标签详情页、归档页、关于页、友链页、留言页和分享页。这些页面共用 base.njk 布局，各自独立渲染内容区。

结语

从 Jekyll 到 Eleventy，最大的感受不是某个具体功能的好坏，而是控制权的转移。在 Chirpy 主题下，你只能做主题允许你做的事；在 Eleventy 上，你做的每一个决定——CSS 变量命名、布局如何分层、搜索索引的权重分配——都是你自己的决定。当然代价是每件事都要自己动手。如果你喜欢开箱即用，Chirpy 仍然是更好的选择。但如果你想完全掌控博客的每一层，Eleventy 值得花时间。

项目代码完全开源，在 GitHub 上可以找到。你可以直接 fork 使用，也可以只参考某个模块的实现——比如 Fuse.js 搜索的集成方式、三栏布局的 CSS 实现、或者 GitHub Actions 多平台部署的 workflow 配置。

为 Chirpy 添加 Twikoo 评论：一次插件开发记录

2026-04-26T00:00:00Z

Chirpy 是个出色的主题，但它原生不支持 Twikoo 评论。我想在现有的 Giscus 系统旁添加 Twikoo，又不想修改主题源码。解决方案经过多次迭代：一开始使用 Jekyll 插件，后来尝试 footer.html 模板注入，最终采用本地构建后推送的工作流程，以确保所有部署平台的行为完全一致。

为什么要在 Giscus 之外再加一套评论系统？Giscus 本身很好——免费、无广告、评论数据存储在 GitHub Discussions 里，跟项目代码在同一个屋檐下。但它有一个门槛：读者必须拥有 GitHub 账号才能发言。这听起来不算什么，直到你真的遇到那些场景。一位来自中国的读者也许能稳定访问你的博客，却怎么也打不开 GitHub 的认证页面；另一位读者可能只是想说一句"好文章"，却要为此注册一个他并不需要的账号。这种摩擦会直接损失评论——很多人看到登录页面就关掉了标签页。

Twikoo 提供了另一种路。它支持匿名评论，不需要任何第三方账号，读者打开页面就能打字。代价是你需要自己维护一个后端，可以是腾讯云 CloudBase、Vercel，或者自建服务器。对我来说，这个代价完全值得：同时提供 Giscus 和 Twikoo，就等于同时照顾了两类读者——那些愿意用 GitHub 身份发声的，和那些只想留下只言片语的。

但 Chirpy 主题的模板打包在 Ruby gem 里，你不能直接在项目目录中修改它们。官方只内置了 Giscus、Disqus 和 Utterances 三种评论系统。如果你想加 Twikoo，绕过 gem 的束缚，就得动主题的源文件。最直接的办法是 fork 主题，改完再用自己的 fork。但这引入了长期的维护成本：每次 Chirpy 发布更新，你都得把变动合并到自己的 fork 里，而评论功能本身并不会因为主题升级而有什么变化。我希望的方案是能跟上游主题保持同步的，不需要维护一个独立的 fork。

于是我开始寻找一种不触碰主题核心文件，就能把 Twikoo 注入到每篇文章中的方法。这个过程经历了三次尝试。

第一次尝试是写一个 Jekyll 插件。我创建了一个后渲染钩子（post-render hook），在 Jekyll 构建完每个文档之后运行。它检查输出是不是 HTML，验证当前文档是不是一篇文章，确认无误后，把 Twikoo 所需的容器和脚本注入到结束标签之前。这个方案在本地跑得很好，在 Cloudflare Pages 上也正常。但推上 GitHub Pages 后，评论模块消失了。问题出在 GitHub Pages 的构建环境对自定义 Jekyll 插件的处理方式上——它在构建过程中根本不会执行第三方插件。我开始以为是自己钩子类型选错了，于是换了钩子类型，加了错误日志，清了缓存，反复调整配置。折腾了几周之后才确认，这不是代码的问题，是平台本身不支持。完整的插件源码现在还在我的仓库里，路径是 _plugins/twikoo-inject.rb，供那些使用兼容平台的读者参考。

第二次尝试换了个思路，绕开插件系统。我用 Liquid 模板把 Twikoo 直接嵌入到 _includes/footer.html 里。footer.html 是站点模板的一部分，Jekyll 在正常构建周期中会处理它，不管插件有没有被加载。这个想法本身是成立的，但实际效果依然不稳定。GitHub Actions 的构建环境在处理模板 include 的细节上与其他平台存在差异，导致 footer include 在某些构建中触发了，在某些构建中没有。这时候我意识到，真正的问题不是用什么方式注入 Twikoo，而是不同的构建环境对同一份源码的解释并不一致。

第三次尝试彻底改变了思路。既然构建环境不可控，那就不让它们构建。我在本地先跑 bundle exec jekyll build，把生成的 _site 文件夹推送到部署仓库。托管平台只负责提供静态文件，不执行任何构建命令。这种方式下，不管你把 _site 部署到 GitHub Pages、Cloudflare Pages 还是 Netlify，输出都是你在本地看到的那一份。它不是用哪一个平台的标准去构建，而是你自己决定了标准的版本。

具体的注入方式仍然是利用了 _includes/footer.html 模板。区别在于，之前是让平台去渲染这个模板，现在是在本地渲染好再推送。为了防止重复注入，我在 Twikoo 容器上加了独特的数据属性作为标记，这样即使文章本身包含关于 Twikoo 的代码示例，注入逻辑也不会误判。这是一个自己写插件时很容易踩的坑——你的文章内容恰好提到了注入目标，结果把自己排除在外了。

UI 上我做了一个切换按钮。因为 Giscus 是由 Chirpy 主题自身渲染的，没办法隐藏，所以 Twikoo 默认不显示。读者点击"展开 Twikoo 评论"之后才会出现输入框，按钮文字会同步切换成"收起"。这样做的另一个好处是实现了懒加载：Twikoo 的 JavaScript 库只在第一次点击按钮时才加载并初始化。如果读者没有评论的意图，他们的浏览器就不会多下载一个库。

样式方面我用了 Chirpy 定义的 CSS 变量——--border-color、--text-muted、--link-color 这几个。切换按钮和分隔线在浅色和深色模式下自动适配，不需要为每种模式写两套样式。宽度对齐到 max-width: 800px，与文章正文保持一致。边距设成 0.5rem auto 2rem auto——顶部给一点呼吸空间，底部留出更充分的分隔，因为下面是 footer 的开始位置。

配置很简单。如果你只想用 Twikoo，不要在 theme 的评论 provider 字段里填任何值，否则 Chirpy 会因为不认识的 provider 报错。如果你想同时使用 Giscus 和 Twikoo（像我的博客这样），就把 provider 保留为 giscus，主题会正常渲染 Giscus，Twikoo 则通过我们注入的方式独立显示。另外需要在 _config.yml 里加上一行：

plugins_dir: _plugins

这行配置告诉 Jekyll 从 _plugins 目录加载自定义插件。如果缺少这行，Jekyll 可能找不到你放在那里的脚本，具体表现因调用方式而异。

部署方面，我现在的流程是这样的。源码和 _site 在同一个仓库里。本地构建完成后，通过 GitHub Actions 把 _site 目录推送到 GitHub Pages。对于 Cloudflare Pages 和 Netlify，同样推送 _site 目录，但在它们的控制台中关闭构建功能，只保留部署和托管静态文件的能力。Netlify 的免费版每月有 300 分钟的构建时间限制，跳过构建步骤还能省下这些额度给其他项目用。

如果你想自己配置一遍，各平台的设置要点是：GitHub 仓库设置中启用 Pages，选择 GitHub Actions 作为构建源；Cloudflare 创建 Pages 项目时关闭构建选项，部署目录设为 _site；Netlify 创建站点时同样关闭构建命令，发布目录设为 _site。然后写一个简短的部署脚本来自动化整个过程，每次需要发布时在本地先 bundle exec jekyll build，然后提交 _site 的变更并推送。你可以参考这个骨架：

#!/bin/bash
set -e
bundle exec jekyll build
cd _site
git add .
git commit -m "Deploy $(date)"
git push deploy main

本地构建工作流程有几个实实在在的好处。一致性是最重要的一条——你本地是什么样，线上就是什么样，因为用的是同一台机器、同一套 Ruby 版本和 gem 版本构建出来的。调试也变得更简单：如果线上页面出了问题，你把本地 _site 里对应的 HTML 打开，和线上的比较，差异一目了然。部署速度更快，推送 git 提交只需要几秒钟，不需要等平台慢慢跑构建。最后，你掌握了控制权——平台可能会在某个星期二悄悄升级 Ruby 版本，但你的构建环境只会在你主动升级时才会变化。

现在每篇文章底部都有两个评论系统。Giscus 默认可见，与主题风格融为一体。Twikoo 默认隐藏，通过切换按钮访问。它们各自独立工作，读者按自己的情况选。如果你只是在浏览内容，两个都可以忽略，页面不会因为你没评论就加载多余的脚本。

完整的源代码在我的 GitHub 仓库里。你需要关注三个文件：_includes/footer.html（模板注入的逻辑）、_plugins/twikoo-inject.rb（插件注入版本，供兼容平台使用）、以及 _config.yml 中与 Twikoo 相关的配置项。这些文件可以直接复制到你的项目中使用。

最后记录一下这个方案在迭代过程中的关键节点：4 月 25 日完成初始版本，包含切换 UI 和懒加载；同一天将钩子从 site:post_render 改为 documents:post_render，提升了兼容性；5 月 2 日修复了自我排除的 bug——使用独特 data 属性做标记后，文章内容不再影响注入结果；5 月 7 日尝试 footer.html 模板注入作为纯插件方案的替代；5 月 8 日最终转向本地构建工作流程。到这一步，我在不同平台上看到的终于不再是三种不同的结果。

Copilot的数据政策变更：AI时代的开源思考

2026-03-28T00:00:00Z

近日，GitHub 宣布更新 Copilot 隐私政策：从 2026 年 4 月 24 日起，将默认使用 Copilot Free、Pro 和 Pro+ 用户的交互数据（包括输入提示、输出建议、代码片段及相关上下文）来训练和改进 AI 模型。除非用户主动在设置中 opt-out——关闭"允许 GitHub 使用我的数据进行 AI 模型训练"选项——否则数据将被用于模型训练。Copilot Business 和 Enterprise 企业用户则不受此次变更影响。这一政策调整迅速引发开发者社区讨论，许多人担忧自己的代码交互数据在不知情下成为微软 AI 的"免费燃料"。

在当前法律和许可证框架下，AI 模型在训练时可以较为自由地爬取和学习 MIT、BSD 等宽松许可证的项目，因为这些协议对使用、修改和衍生几乎无额外限制，仅需保留基本版权声明即可。对于 Apache 2.0 许可证的项目，AI 应至少在生成的代码注释中保留原始署名和来源提及，以尊重其"保留 NOTICE 文件和修改说明"的要求。比如，你用了一段来自 Apache 项目的代码，AI 生成的新代码里应该加一行注释说明原始来源。

对于 GPL 系列（强 Copyleft 协议），情况更复杂——如果训练导致生成实质性衍生代码，可能需要考虑开源义务。但这里有个实际操作中的困境：GPL 的"传染性"条款要求衍生作品必须以相同许可证开源，这在传统软件开发中容易界定，但 AI 模型的训练过程本身不产生"可见代码"，所以 GPL 条款的适用存在争议。这更多依赖 AI 提供商的合规自律。现实中，大多数开发者在复用开源代码时往往忽略完整标注，何况是 AI 模型？但正因为 AI 是规模化"学习"工具，我们更有理由从训练源头强化版权尊重机制。例如，通过提示工程或后处理，让 AI 在输出时自动添加来源注释。这不仅能减少潜在纠纷，还能培养整个生态的版权意识。

我自己的大部分项目采用 BSD-2-Clause 许可证（而非 BSD-3-Clause），其高度包容性让我欢迎 AI 爬取和学习——BSD 协议的海纳百川精神，本就鼓励广泛使用与创新。对于我使用 Apache 2.0 的项目，我的态度则更谨慎：AI 至少应在注释中浅浅提及原始来源和许可证，这既是基本尊重，也能避免后期合规风险。

目前看来，现有的开源许可证对 AI 训练这一新场景准备不足。MIT/BSD 等宽松协议在 AI 时代显得"过于友好"，而 Apache 和 GPL 则缺乏针对机器学习的明确条款。我认为，在不久的未来，各大开源基金会和社区很可能针对 AI 训练进行一次系统性更新，例如新增"AI 训练授权"子条款、要求模型输出时强制保留归属信息，或引入"训练时脱敏+溯源"机制。

更让我不满的是：微软一方面使用（包括免费用户在内的）大量开发者交互数据来训练 Copilot，提升模型能力；另一方面，Copilot 免费额度和功能限制依然较为吝啬。Copilot Free 每月仅 2000 次代码补全请求，而 Copilot Pro 定价为每月 10 美元。这相当于让普通开发者在不知情或默认同意下成为"免费劳工"，却未获得对等的回报。这样的商业模式是否公平，值得开发者深思。微软历史上确实多次"毁灭"过优秀产品——从诺基亚、Windows Phone，到如今的 GitHub 生态。但历史也告诉我们，技术变革往往伴随阵痛。未来尚未定型，我们不必一味悲观否定。

开发者可以积极行动起来：立即检查并 opt-out Copilot 数据训练设置——在 VS Code 中打开 Settings，搜索 Copilot，找到"Allow GitHub to use my data for AI model training"并取消勾选；在开源项目中明确添加"禁止用于 AI 训练"的声明（尽管法律效力待验证）；支持更注重隐私和版权的替代 AI 编码工具；参与开源许可证的更新讨论，推动社区制定 AI 友好规则。开源精神的本质是共享与互惠，而非单向索取。希望 GitHub 和微软在追求 AI 进步的同时，能更多倾听开发者声音，让生态真正实现共赢。

折腾 Docker 和面板之后，我决定不折腾了

2026-03-25T00:00:00Z

最近为了更省心地部署一些软件，我重新拾起了 Docker，顺便装了一个叫 DPanel 的面板来管理容器，和一直在用的 aaPanel 搭配着用。本以为能一劳永逸，结果走了一圈，发现大部分服务还是老老实实地跑在裸机上。

一开始我的想法挺大的：把大部分服务都迁到 Docker 里，比如我的 Halo 博客。想象中，拉个镜像、配个端口，一切干净清爽。但实际操作时，第一个坎儿就卡在了数据库上。我的系统里已经有现成的 MariaDB 在跑，而 Halo 容器需要连这个数据库。容器和宿主机之间的网络、权限、配置折腾了半天——容器里连宿主机 IP 要手动指定，端口要暴露，数据库还得允许远程连接。搞了一圈还是别扭，最后放弃了。

于是我退了一步，只在 Docker 里跑一些相对独立的应用，比如那些不需要跟宿主机数据库或文件系统深度绑定的项目。剩下的软件，比如 Halo 博客系统、OneDev 代码仓库等，继续裸机部署。一个混合的方案，虽然没那么"潮"，但胜在稳定、省心。

其实我也想过把 Halo 换成更轻量的 Typecho，把 OneDev 换成 Gitea。Typecho 的 SQLite 模式连数据库都省了，Gitea 也是出了名的轻。但是一算账：现有数据要导，主题要换，插件要重新配，使用习惯也得改。折腾下来至少一两天，而且最近还有其他正事要忙。算了，凑合用吧。我做的唯一优化是：把 JVM 的内存参数调了调——Halo 默认的堆内存给得比较大，我根据实际访问量降到了合理范围；同时把 Docker 里一些不再用的镜像和容器清理掉，腾出了大概 700 来 MB 的内存空间。勉强能用，也就没再动。

写了这么多，其实想劝一句：别在博客系统上反复纠结。选一个顺手的（比如 Halo、Typecho、Hugo 都行），把重心放到写文章上。今天想换这个，明天想换那个，最后发现文章一篇没写，日志倒是写了一堆迁移笔记。有那工夫，不如老老实实坐下来，认真写一篇有内容的文章。系统只是工具，内容才是根本。用顺手了就别瞎折腾——这话也是对我自己说的。

小米兰亭：更适合中文长文阅读的博客字体

2025-07-26T00:00:00Z

最近调整博客字体，发现小米兰亭在正文阅读上，可能比更纱黑体更适合一些。

更纱黑体是我之前一直在用的字体——它融合了思源黑体和Iosevka，现代感强，字符也全。但阅读的体验感始终感觉没有系统默认字体一样好。直到换到小米兰亭，对比才明显：小米兰亭的字母更粗、更圆润，整体观感更舒适，长时间阅读不容易累。

小米兰亭在设计之初就考虑了阅读感受，笔画清晰、灰度均匀，用在博客正文里，字与字的呼吸感刚刚好。

不过，字体效果很大程度上取决于操作系统。Windows的字体渲染一直是个大问题——ClearType再怎么调，和macOS的原生渲染比起来，总像隔着一层纱。换什么字体都难有质的改善。而iOS这边，无论什么字体，渲染出来都线条清晰、边缘平滑，赏心悦目。

Linux方面，至少KDE Plasma的渲染效果不错，开箱即用就有舒适的字形和间距。其他桌面环境我没深入用过，暂时不作评价。

其实字体选择真的不能只看个人偏好：博客的文章标题之前一直是繁体，我感觉标题用繁体有古风质感，正文用简体便于阅读，但经常被各位朋友们吐槽说看不懂标题。我只好换个字体，但是始终没有华英明朝体的感觉，折腾半天才发现，ZSFT默认提供的华英明朝体本来就有简体版本——它默认调用了T字符集的繁体版本，而不是Classic简体字体。修改之后，标题终于回归简体，质感稍微差了点，但可读性大大增强。

说到底，字体这件事，没有绝对的好坏，只有适合不适合。如果博客以正文为主，想在Windows和macOS之间找个平衡，不妨试试小米兰亭。至少目前，这是我感到最让我舒适的阅读字体。

至于霞鹜文楷这款人气相当高的字体，我个人的看法是，它更像是手写的楷体，而非标准的印刷楷体——在计算机字体分类中，它更接近艺术字的范畴。诚然，许多人青睐它，因为它比常见的印刷体多了几分手写的温度与活力。但对我而言，艺术字用于正文阅读并不理想，且其风格与我的博客调性也不太契合。

Linux的默认字体大多从文泉驿系列转向了思源系列。思源黑体总的来说是一款中规中矩、平衡稳定的字体，相较于略显稚气的文泉驿微米黑，设计上更为成熟。或许是因为以前缺乏优秀的开源字体，大多数Linux发行版才更倾向于选用文泉驿系列；而如今，大多数发行版和桌面环境都已内置了思源宋体和思源黑体。

GitHub 之外的选择：七个代码托管平台的真实体验

2025-05-21T00:00:00Z

老实说，2025到2026年，GitHub已经不是"偶尔抽风"，而是常态化拉胯了：免费Actions分钟数被成群的机器人挖矿账号薅到秃，正常用户排队等到天荒地老；安全漏洞修得比乌龟爬还慢，供应链攻击年年有；国内访问时好时坏，CI/CD 一跑就卡，部署个东西像抽奖。最气人的是，微软继续在那儿装没事人，卖企业版赚得盆满钵满，免费用户当韭菜割。

很多人忍无可忍，开始四处找备胎。国内平台、海外平台、自建方案，全部扒一遍。

国内平台

强制实名和手机号绑定是绕不过去的门槛，国内平台通病。

Gitee（码云）是目前国内最不恶心的选择。国内访问速度最快、稳定性最高，功能基本齐全：Pages、Wiki、Issues、PR、Release、Actions（虽然弱但能用）。可以外链项目卡片到自己网站，免费私有仓库多，社区中文支持完善。但 Actions 算力垃圾，免费额度用完就 GG，敏感内容随时可能被要求整改。如果人在国内、要日常开发、要快，Gitee 是目前唯一靠谱的国产主力平台。

GitLink 由 CCF 和中科院背书，完全开源，支持 Pages、Wiki、Issue 等基本功能。但名字容易和 GitLab 混淆，社区活跃度低，Issue 响应慢，国内访问速度一般。学术圈可以考虑，日常开发还是 Gitee 更稳。

Coding（腾讯云）有大厂背书，企业级服务稳定，支持 CI/CD、项目管理、代码托管一体化。但免费额度少，付费门槛高，界面臃肿，操作繁琐，数据隐私存疑。企业用户可以考虑，个人开发者不建议。

海外平台

CodeBerg 由德国非营利组织运营，完全开源，数据受 GDPR 保护。Pages 功能强大，支持 Hugo/Jekyll 等静态生成器。社区友好，真人客服响应快。国内访问需要代理，社区规模小。追求开源精神和隐私保护的话，这是首选。

GitLab 功能齐全，CI/CD、项目管理、代码托管一体化，自托管版本免费。但商业化严重，免费版功能受限，国内访问慢。企业用户可以考虑。

SourceHut 极简设计，无广告、无追踪，完全开源。界面简陋，新手不友好，国内访问需要代理。极简主义者的选择，不适合大众。

自建方案

Gitea 轻量级，资源占用低，完全开源，支持 Pages、Wiki、Issue 等功能。需要自己维护服务器和备份。有服务器资源的开发者首选。

OneDev 实现 DevOps 一体化，代码托管加 CI/CD 加项目管理，轻量级，完全开源。同样需要自行维护服务器。

GitHub 不再是唯一选择。国内用户可选 Gitee 作为主力，海外用户可选 CodeBerg 追求开源精神，有服务器资源可自建 Gitea 或 OneDev。重要的是找到适合自己的平台，而不是被一个平台绑架。

犀飞利帝国二：花三百块买到最适合我的钢笔

2025-03-30T00:00:00Z

怎么说呢，这支笔价格相对便宜些，因为是小胜利尖、TD上墨加钯银材质笔尖，所以在犀飞利的产品线里算是低端货，我花300买到的。

玩笔的应该都知道胜利尖和TD上墨这些，不多废话。这支笔对我来说真的是完美日用笔：拔插式笔帽、硬笔尖、上墨干净快速……颜值也很高。我不太喜欢帝国一或者塔格那种笔身设计，感觉直接穿越回文艺复兴时代了。我玩复古钢笔是体验上世纪的玩意，不是体验文艺复兴的设计风格……是吧？

这支笔其实可以比作低配版的犀飞利潜艇主编，都是钢帽，区别在于笔尖由大胜利尖降配为小型，潜艇上墨降级为TD上墨。

好了，就这么多。图片可以搜索别的博主拍摄的，我只讲我的使用体验，真没啥更多好说的了。

CSS 实现正文首行缩进：一次排版美学的实践

2025-02-28T00:00:00Z

更新：由于显示 Bug 较多，目前本站已放弃正文段落首行缩进。

在搭建这个博客时，我始终觉得，文字的呈现方式本身就是内容的一部分。最近在微调博客样式时，我花了不少时间去雕琢一个看似微不足道，实则关乎阅读气质的细节——中文正文的首行缩进。

起初，我的做法很粗暴，仅仅是给所有的 <p>标签加上了 text-indent: 4em;的声明。在纯粹的视觉层面，这确实奏效了：文章段落整齐地向右挪了四格，透出一种传统印刷品般的秩序感。然而，这种「一刀切」的快感很快就被打破了。当我滚动到列表或引用区块时，问题暴露了出来——那些本该紧凑排列的列表项，因为外层包裹着 <li><p>的结构，竟然也跟着缩进了进去。这种错位在视觉上显得极不协调，原本灵动的排版瞬间变得有些「神经质」。

这让我意识到，真正的「优雅」，不在于强制统一，而在于懂得克制。

于是，我开始重新审视 CSS 选择器的边界。问题的本质其实很简单：Halo 主题（以及大多数现代 CMS）为了语义化和样式可控，常常会将列表项内的文本包裹在一个额外的 <p>标签中。如果我们直接攻击 p，就必然会误伤无辜。解决之道，在于划定清晰的「势力范围」。

我放弃了全局的 p选择器，转而将目标锁定为 .post-content > p。这意味着我只关心那些直接挂载在文章内容容器下的段落，而不去干涉嵌套在其他元素内部的文本。紧接着，我用了一组「豁免条款」来修复那些被误伤的区域：

p:not(li p):not(blockquote p) {
    text-indent: 2em;
    margin-top: 0.8em;
    margin-bottom: 0.8em;
}

这几行代码就像是交通协管员，把跑错道的列表段落拉回了原位。至此，排版终于恢复了它应有的逻辑：列表归列表，引用归引用，而正文段落则保持着它端庄的缩进。

在这个过程中，我还确立了几条不成文的「排版洁癖」准则：

首先是单位的抉择。我坚持使用 em而非 px。在响应式设计大行其道的今天，固定的像素值就像刻舟求剑，无法适应不同屏幕尺寸下的字号变化。而 em是相对单位，它会随着父级字号的变化而自动伸缩，确保在手机端和桌面端，缩进的比例始终是和谐的。

其次是移动端的微调。在手机屏幕上，过宽的缩进反而会挤压宝贵的阅读空间。因此，我引入了一条媒体查询规则：当屏幕宽度小于 480px 时，将缩进从 4 格缩减为 2 格。这是一种对阅读场景的尊重，也是技术服务于人的体现。

最终，这一切都收敛成了一段干净、纯粹且不依赖 JavaScript 的 CSS 代码。它没有破坏原有的 HTML 结构，也没有引入复杂的脚本逻辑，仅仅是站在 CSS 的肩膀上，完成了一次对视觉秩序的温柔校正。

这种「只动样式，不动结构」的思路，不仅适用于 Halo，我想对于 Typecho、WordPress 乃至静态博客生成器来说，都是通用的。毕竟，好的排版不该是代码的堆砌，而是一种在方寸之间寻找呼吸感的平衡艺术。

告别 GitHub，拥抱 CodeBerg：一个开发者寻找温暖家园的故事

2025-02-18T00:00:00Z

我们曾拥有一个有温度的数字家园。深夜有人耐心帮你 debug，Issue 区能吵起代码哲学，客服甚至会因为你一句"这个用户名对我意义重大"而手动解锁。那是 2013 到 2018 年的 GitHub。

然后微软来了。带着收购合同、Excel 表格和"协同效应"的 PPT，把一切贴上价签。从此，GitHub 从一个开发者社区逐渐变成一个商业平台。

如今打开首页，满眼 AI 垃圾 PR、低质爬虫项目、永不回复的机器人，以及 2025 年接连爆出的 Copilot 系列漏洞——EchoLeak 零点击泄露、CamoLeak 提示注入、已删仓库数据仍在被访问。供应链攻击频发，秘密像筛子一样漏。安全团队在忙什么？忙着把我们的代码喂给 Copilot，再高价卖回来。

我愿意付钱。真的愿意每个月掏钱，只求换回那个有血有肉的社区，换回深夜回复的三页分析，换回尊重用户身份的真人支持。但微软连让我付费赎回温暖的资格都不给。它只要免费的代码、免费的信任、免费的情感，最后再把这一切变成 Azure 账单和股东回报。

我们失去的，远不止一个平台。失去真人客服，取而代之的是全球铁板政策和"风险控制"优先；失去休眠用户名解锁的同理心，取而代之的是法务胜利；失去纯粹互助，取而代之的是 KPI、流量变现和 AI 水军淹没真问题。更残酷的是，它用我们的代码训练模型，却在漏洞里让无数人的秘密暴露。这不是 bug，这是商业模式本身。

这些感受不是空穴来风。你可以在网上搜到大量开发者在 2025 年的吐槽帖——从 Copilot 的隐私政策到 Actions 的免费额度缩水，再到客服形同虚设。如果你也在用 GitHub，去看看你的 Developer settings > Copilot 页面，默认情况下，你的数据已经被勾选为"可用于模型训练"了。

CodeBerg：开源精神没有死，它只是换了地址

温暖从未灭绝，它只是回到了更小、更纯粹的地方——CodeBerg。由德国非营利组织 CodeBerg e.V. 运营，基于 Forgejo（一个开源的 Git 托管软件），完全社区驱动。数据放在欧盟，受 GDPR 严格保护。没有广告、没有数据贩卖、没有隐藏监控。免费，无任何商业变现压力。这里像早年的 GitHub：Issue/PR 流程干净利落，有人认真回复你的问题（是真的有人，不是机器人），Pages 功能简单好用——新建仓库、推送到 pages 分支、自动 HTTPS、自定义域名，推送即更新，支持 Hugo/Jekyll 等主流生成器。社区小而友好，开发者真正被听见。不是规模最大，但足够安全、足够透明、足够有温度。

想试试吗？哪怕只是把个人博客或项目文档先迁过来，体验一下推送即发布的纯粹感。CodeBerg.org 里有最清晰的 Pages 教程。微软用贪婪玷污了广场，但广场的精神没有死。它在 CodeBerg 安静地活着，等着每一个厌倦了冰冷算法的人回家。

在 Zfile 和 OpenList 上挂载天翼云盘：一个设备锁问题的解决记录

2025-01-19T00:00:00Z

用 OpenList 或 Zfile 这类网盘聚合工具，蓝奏云基本输个密码就行，可天翼云盘总卡在设备锁这一步。网上教程大多让去 e.dlife.cn 扫码关，问题是那页面老转圈圈，二维码根本刷不出来。

问客服才知道，真正能关设备锁的地方是 e.189.cn/user/index.do。但得先在浏览器里登录天翼云盘。没登的话，先去 cloud.189.cn 正常登录，再开上面那个链接，就能直接进个人中心。

进去后在账号安全或设备管理里找设备锁开关，关掉就行，可能要短信验证。完成之后回到 OpenList 或 Zfile 重新加天翼云盘，一般就能正常挂载。

为什么我只用 BSD-2-Clause 和 Apache 2.0：一个开发者的许可证观

2025-01-16T00:00:00Z

大多数开源项目在用 GPL 或 MIT。这两个我都不喜欢。这些年，我不再盲目追主流。GPL 的"父爱式管制"让我不舒服——它通过限制开发者来保护用户。MIT 的"毫无节制的宽容"也不对味——说"随便用"等于放弃所有责任。我的原则很简单：只留最基本的约束，把最大的自由给用户。这自然把我引向 BSD，尤其是 BSD-2-Clause。

许可证从限制性到宽松性，像一条光谱。GPL 和 MIT 站在两端，我都避开。GPL 认为真正的自由需要法律强制。它用法律确保代码被修改时，开源精神能一直传递。听起来高尚，可它是通过限制开发者来保护用户。这和我的"最大自由"原则冲突。我希望用户自由，但不想以牺牲开发者对代码的掌控为代价。

1983 年，Richard Stallman 在麻省理工学院的实验室里，打印机卡纸了。他想修改打印机驱动程序，但厂商拒绝提供源代码。那一刻，他决定创建一个完全自由的操作系统——GNU。GPL 就这样诞生了。Stallman 的理想是崇高的，但他的方法是通过法律强制来实现自由。这就像一个父亲，为了保护孩子制定了一整套规则，限制孩子的行为。孩子确实安全了，但也失去了探索的自由。

MIT 走向另一个极端，太天真了。把代码扔出去说"随便你怎么用"，听起来开放，实则是放弃所有作为作者的道德主张。按 MIT 的规则，别人能把你名字完全抹掉，能用你的作品干坏事，甚至能用专利攻击别人——MIT 根本没专利保护条款，而且完全没有回馈义务。这不是自由，是放弃责任。

BSD-2-Clause 找到了中间地带。它又叫简化 BSD 或 FreeBSD 许可证，就两个要求：保留版权声明，加个免责声明。就这么多，没有更多法律条款要读。它给的自由很惊人。你可以把代码用在任何地方：商业、个人、教育。随便改。可以闭源分发，不用开源自己的修改。可以整合到完全不同许可证的项目里。没有专利报复条款的麻烦。不像 GPL，没有"传染性"要求逼你把自己的代码也开源。但 BSD-2-Clause 仍保留基本标准：用户必须通过署名承认你的工作，不能假装是他们写的；你也受责任保护，有人用你代码出问题，那是他们的事，不是你的。

为什么不用 BSD-3-Clause？第三条款说未经许可不能用作者名字为产品背书。理论上合理，实际中却很少被违反。它给大多数小项目添了不必要的法律复杂性，而且真想滥用你代码的人总会找到办法绕开。BSD-2 更干净，更贴合"最小约束"的原则。

我根据不同场景用不同许可证。个人项目——脚本、小库、实验代码——一律 BSD-2-Clause，简单，鼓励使用和分享。大项目，尤其是框架或涉及专利的代码，我用 Apache 2.0。现代软件里专利保护很重要，Apache 在这方面处理得好，同时还保持宽松。文档和创意作品用 CC BY 4.0，署名要求清楚。

刻意避开的许可证：GPL 和"最大自由"原则冲突。MIT 太宽松，放弃太多。SSPL、BSL 之类的"源码可用"许可证不是真正的开源——就算源代码可见，它们也限制你怎么用代码。

给刚起步的开发者建议：从 BSD-2 开始。它直截了当，不会用一堆条款把你搞晕。在 README 开头用白话把许可证说清楚。项目里保持一致。想清楚你的受众：要广泛传播就用 BSD 或 Apache 这样的宽松许可证；做社区项目可以考虑 MPL 这样的弱 copyleft。有强烈的道德立场？去研究研究 Hippocratic License 这类变体。

选许可证不只是技术决定，是价值观的表达。MIT 说"我不管，随便用"。GPL 说"你可以用，但得听我的——我定义你的自由"。Apache 试图平衡："自由用，但我们互相保护"。BSD 说"这是我送你的礼物。记得谁给的，然后去创造点伟大的东西"。

BSD-2-Clause 简洁优雅。有时候，最简单的就是最好的。

本文采用 BSD-2-Clause 许可证发布。你可以自由使用、修改、分发，只需保留原始署名和许可证声明。

ProtonMail 为什么不值得买：一个隐私邮箱的真相

2024-11-30T00:00:00Z

ProtonMail 确实是开源的，但只开源前端，后端并不公开。这意味着，我们根本不知道邮件在它的服务器上经历了什么处理。当然，一旦后端也开源，隐私性可能随着代码曝光而降低；可后端不开放，又无法保证服务器不会暗中上传数据。这简直成了一个循环论证——所谓"完全隐私的邮箱"，根本就是个伪命题。

2013年，斯诺登揭露了美国国家安全局的棱镜计划。那一刻，全球用户开始意识到：他们的邮件、聊天记录、搜索历史，都在被监控。隐私，成了一个奢侈品。ProtonMail就是在这样的背景下诞生的——2014年，一群来自CERN的科学家在瑞士创立了这家公司，打着"端到端加密"的旗号，承诺给用户一个真正私密的邮箱。瑞士的法律环境确实相对宽松，数据保护法规严格。但问题是：瑞士不是天堂。2019年，ProtonMail被迫向美国当局移交了一位法国活动人士的IP地址和设备信息。所谓的"瑞士隐私保护"，在法律面前不堪一击。

如果隐私性并不绝对，那我们再来看看它的其他功能。免费版容量只有 500MB，邮件带附件的话，一百个不到就用完了。免费用户只能注册一个地址，这点还算可以接受。付费后可以解锁 @pm.me 这个短域名，简洁好看。但问题在于，ProtonMail 不支持国内常用支付方式。如果你费尽周折终于付了款，那为什么不直接自己去注册一个域名呢？有了域名，你就可以轻松设置域名邮箱，国内外很多邮局（比如 QQ、Zoho）都支持。而 ProtonMail 的域名邮箱功能——同样需要付费升级。对新手来说，我之前推荐过的 Yandex 也是不错的选择，它能自动帮你购买并配置 .ru 结尾的域名邮箱。如果你拥有开放 25 端口且具备原生 IP 的云服务器，甚至可以自己搭建邮件系统（比如 Pmail）。这才是真正意义上的"完全隐私"——服务器和后端都在自己手里，不必依赖任何第三方的承诺。

ProtonMail 的付费后体验相较于其他付费邮箱并不差，但免费版体验极其糟糕。隐私保护从来都不是一个技术问题，而是一个信任问题。你信任瑞士的法律，信任 ProtonMail 的承诺，信任他们不会在后台偷偷上传你的数据。但信任是最脆弱的东西，一旦被打破，就再也回不去了。

NDS 与 PSP：掌机黄金时代的一场经典对决

2024-09-09T00:00:00Z

NDS 和 PSP，大概是掌机史上最势均力敌的一对对手。在 2004 到 2005 年之间先后问世，一个是任天堂的创新与巧思的完美结合，另一个是索尼的 3A 大作、高性能硬件规格在移动设备上的体现，即使理念背道而驰，却都在各自的玩家群体中赢得了空前的成功。

先说硬件。NDS 使用了双 3 寸屏（下屏可触控），分辨率为 256×192，触控笔藏在机身里，电池续航 15 小时以上，待机时相当省电。PSP 则是 4.3 寸大屏，480×272 分辨率，比 NDS 细腻得多，能放 MP3、看视频、浏览网页。处理器也比 NDS 强不少，333MHz 与 67MHz 相比较，可以说完全不是一个级别的产物。

但这可不代表NDS在市场上的表现弱于PSP，NDS卖了1.54亿台，是史上销量最高的掌机（但不是最畅销的游戏机，主机平台的PS2是销量最高的游戏机，总共卖出了约1.7亿台），游戏卖了9亿多套。双屏是最大亮点，下屏触控加麦克风，游戏的玩法一也丰富了许多。画个画（《触控卡比》、《节奏天国》等）、吹口气（《任天狗》、《逆转裁判4》等）就能互动，在当时是非常先进的交互理念。游戏阵容也全，从马里奥到宝可梦，老少皆宜。

几个主要版本里，原版NDS被玩家叫"饭盒机"，块头大、屏幕暗，特点是兼容了GBA卡带。2006年的NDS Lite最经典，薄了不少，屏幕亮了很多，续航能到15小时以上，销量占了整个系列的六成。值得一提的是尽管同样兼容GBA卡带，但由于机身变薄，插入GBA卡带后会露出一大截。DSi加了摄像头和SD卡槽，砍了GBA兼容，机身更薄，屏幕也大了一圈。而DSi XL，屏幕更大，4.2寸，看书玩游戏不那么累眼了，就是便携性差点，重了差不多100克。不过值得注意的是，尽管屏幕尺寸更大了，分辨率完全没提升，尽管不累眼，但是游戏画面的锯齿会显著增多，任天堂或许是出于节省生产成本考虑吧。

PSP走另一条路。卖了8000多万台，特点是画面接近PS2，能看电影、听音乐，UMD光盘当时看着特酷。定位像"能装进口袋的PlayStation"，吸引的是硬核玩家，当然，由于PSP的多媒体功能很强大，也是当时市面上比较便宜的影音设备，许多音乐发烧友也会买个PSP用来听歌、看视频，当作MP3播放器使用。关于PSP便宜的原因，是因为当时任天堂在索尼发售PSP之前抢先发售了NDS初代机，且价格只有PSP预售价格的3/1，索尼也不得不为了增强竞争力，压低了正式发售时PSP的售价。

PSP-1000是首发款，最重最厚，280克，续航一般。2007年的PSP-2000瘦了不少，189克，内存翻倍，加载快了，还能USB充电。PSP-3000屏幕做了防眩光，颜色更好，很多玩家说这是最佳版本。PSP Go走纯数字路线，滑盖设计前卫，158克最轻，没有UMD光驱，游戏库受限。最后的PSP Street是廉价版，砍了WiFi，功能简化很多。

游戏方面差距就大了。NDS的顶级大作能卖几千万份：《超级马里奥兄弟DS》卖出3080万份，《脑白金》卖出1900万份，《口袋妖怪·黑/白》卖出1700万份。PSP这边就相当惨淡了，两个顶梁柱《怪物猎人》和《侠盗猎车手》系列也不过才百万销量，其它作品更是惨不忍睹。

为什么差这么多？NDS吃透了休闲市场。《脑白金》、《口袋妖怪》、《马里奥》，这些游戏男女老少都能玩，当时日本就有年轻人为了放置家里老人老年痴呆，特地买了个NDS来给老人玩《脑白金》。PSP定位是"掌机里的PS2"，追求画质和沉浸感，门槛高，受众自然就窄了。同时也有相当一部分买家买来是当作MP3用的，结果就是PSP卖的不算少，但是游戏卖的相当少。

俩机器对比，NDS赢在销量和创意，触控和双屏带来新体验，续航也强。PSP赢在画面和多媒体，3D游戏和影音功能更丰富，但续航只有3到6小时，出门得带充电器。一个偏轻松有趣，一个偏沉浸硬核，各有各的粉丝，各有各的好。

回头看这场大战，智能手机才是真正的赢家。2010年后，iPhone和安卓机把掌机市场冲击得七零八落。Switch是任天堂游戏主机平台的后续篇章，却不是传统意义上的掌机。索尼干脆放弃了掌机市场，只是在PSP之后推出了个无人问津的PS Vita。

……若只从销量数字看，NDS与PSP之间是1.54亿对8000万，似乎算不上"势均力敌"。然而在游戏硬件史里，纯粹以销量定输赢往往失之偏颇。真正让NDS和PSP被并称为"那个年代"的，是它们几乎同时将掌机体验推向了两个截然不同的顶峰，并且在长达五六年的时间里，谁也无法彻底吞掉对方的地盘。

要理解这种均势，可以看看其他世代的主机对抗。

以Wii与PS3为例。Wii全球销量约1.01亿台，PS3约8740万台，数字差距不大，但用户重叠度极低。Wii的体感操作吸引了大量非传统玩家，其软件销量高度集中于任天堂第一方（《Wii Sports》8280万套、《马里奥赛车Wii》3730万套），第三方核心向作品在Wii上几乎卖不动。PS3则依靠《最后生还者》《神秘海域》《战神》等独占大作稳住核心市场，同时兼任蓝光播放器角色。两者更像是错位竞争，而非正面交锋。更关键的是，Wii的后期销量断崖式下跌，PS3却缓慢爬升并反超——这并非"势均力敌的缠斗"，而是一场先扬后抑与后来居上的错时赛跑。

再往前看，Game Boy Advance vs 诺基亚N-Gage则是一边倒。GBA销量8150万台，软件库超过1500款；N-Gage生命周期仅两年，销量约300万台，被玩家戏称为"侧握通话面包机"。这连对手都谈不上。

而任天堂3DS与PS Vita的对决更接近NDS/PSP时代的余波，但结果却大不相同。3DS经历首发降价后卖出7590万台，PS Vita虽有OLED屏幕、背触板、双摇杆等超前硬件，却因索尼第一方支持薄弱、专用记忆卡昂贵、第三方纷纷撤退，最终销量估计在1000万至1600万台之间（索尼未正式公布）。这是一场明显的碾压，而非均势。

反观NDS与PSP，两者在2004–2010年间始终保持高度重合的生命周期。NDS用双屏触控打开蓝海，PSP用多媒体性能守住红海；NDS在日欧美全面开花，PSP在亚洲部分地区（尤其日本）凭借《怪物猎人携带版》系列一度反超；NDS的软件销量碾压PSP，但PSP的硬件出货量从未崩盘。更重要的是，两者在玩家群体中形成了长期的分庭抗礼——直到今天，关于"哪台机器更值得怀念"的争论依然存在。这种"各走极端却各有所长"的局面，在掌机史上绝无仅有。

另外，NDS在国内的普及离不开一个特殊角色——烧录卡。2006年前后，以R4、DSTT、AK2为代表的烧录卡开始大规模流通。它们本质上是一张插槽1（Slot-1）的卡带，内置TF卡插槽，通过硬件或固件欺骗NDS的验证机制，直接从存储卡加载游戏ROM。一张烧录卡售价约50–150元，配合一张1–2GB的TF卡，就能装下20–30个NDS游戏。对于当时国内普遍缺乏正版购买渠道的学生玩家来说，烧录卡几乎是唯一可行的选择。

烧录卡对NDS生态的影响相当复杂。积极的一面是，它极大降低了体验门槛，让NDS在国内的保有量迅速膨胀，甚至超过PSP（PSP同样有自制系统，但破解流程更复杂，需要特定漏洞游戏或潘多拉电池）。消极的一面是，NDS的正版软件销量因此受到严重冲击——全球1.54亿台硬件对应9.4亿套软件，软硬比仅为6.1，远低于GBA（约8.5）或3DS（约6.5但含大量数字版）。大量第三方厂商在NDS后期放弃了原创中轻度游戏，因为"ROM上线即被盗"。

关于烧录卡的具体工作原理、各品牌的兴衰时间线、与PSP自制系统（M33、PRO、ARK）的对比，以及任天堂后续通过系统更新、卡带加密等手段的反制措施，将在下一篇中详细展开。

（待续）

怎么选邮箱？来看看我的选择历程和建议吧

2024-09-07T00:00:00Z

先聊 Outlook。国际邮箱，国内能直接登，不用折腾。光这一点，就比 Gmail 强。

它有个好处：某宝能买到五位甚至更短的靓号，不贵。买了第一件事，改密码，绑手机和辅助邮箱，开两步验证（2FA）。不然无良卖家可能收回，风险大。Outlook 能加十个别名，够用。

提醒：Outlook 有过严重漏洞，账号容易被盗。闲鱼上不少低价 Minecraft 正版号，就是用被盗的 Outlook 注册的。买 Minecraft 号，别用 Outlook 邮箱的微软账号。这漏洞至今没完全修复，一定要开两步验证。

缺点也明显：垃圾邮件过滤太神经质。我连微软官方通知都被扔进垃圾箱过，哭笑不得。解决办法简单：常去垃圾箱看看，把正常邮件标记"不是垃圾"，系统会学乖。

好名字早被注册光了。两条路：要么买短号当主账号，加别名用；要么玩点花的——注册其他国家域名的 Outlook。方法很简单：把微软账户国家/地区改成法国，再添新邮箱，就有 @outlook.fr 可选。我搞了个 .fr 的，像"friend"缩写，有意思。德国 .de、意大利 .it、印尼 .id 之类的，选择不少。

再聊 Foxmail。不得不提 QQ 邮箱，很多人瞧不上，其实功能强。一个 QQ 号能挂三个邮箱：数字 @qq.com、英文 @qq.com，还有重点——Foxmail 邮箱。在 QQ 箱设置里申请 @foxmail.com 地址就行。

这个域名国际上接受度不错，关键是发的邮件几乎能 100% 过 Outlook 的垃圾邮件过滤。所以说，Outlook + Foxmail 是国内收发邮件的黄金搭档。

再说说 iCloud 邮箱。我现在主用这个。收信速度没传说中慢，界面干净，和苹果设备无缝衔接。免费版给 3 个"替身邮箱"，能保护真实地址。

但没苹果设备的话，用起来是灾难，网页版体验太局限。基本是把你绑在苹果生态里。另外，国内版 iCloud+ 是阉割版，想要自定义域名这些完整功能，得用外区 Apple ID。

Gmail 在国内？访问是问题，不稳定。我都是用其他客户端代收，当备胎。

国内老牌邮箱，163、126、yeah、sina、sohu，还有国外的雅虎，能用，但没非用不可的理由。不跟主流平台捆绑，当纯备胎也行。

最后说小众选择。这次重点看了它们的域名邮箱功能，发现不少门道。

Yandex Mail，俄罗斯的。邮箱服务国内访问一般没问题，网盘不能裸连。VIP 账号能弄域名邮箱，不过不是买域名给你用，只是代理转发。服务器在莫斯科，东欧地区投递成功率高。用了动态 IP 池，对发营销邮件（EDM）有帮助。免费版每日发信限 200 封，没中文界面。内置邮件翻译是亮点，但对中文支持远不如谷歌和 QQ。

Zoho Mail，主业是企业邮箱，个人免费版体验不错。以前短 @zoho.com 难注册，现在常见 @zohomail.com。

最硬核的是：免费版就能绑自己的域名，变成真正的 you@yourcompany.com。免费套餐支持最多 5 个账户和 5GB 存储。小团队或个人品牌，零成本建立专业形象，神器。

后台功能丰富，端到端加密、分布式存储保证海外访问速度，但设置 MX 记录、SPF/DKIM 对新手有门槛。还有个优势：和 Zoho 自家 CRM、项目管理工具无缝集成。比如，直接把客户邮件转成 CRM 线索或项目任务，自动化程度高。付费高级版安全和协作功能更完善。

永生 601A：现产唯一的胜利尖钢笔

2024-08-16T00:00:00Z

说是"现产"，其实上海君来只是把老永生的胜利尖库存，重新装到 601A 的笔杆上。真正的胜利尖工艺，早跟上世纪末永生制笔厂的变迁一起散了。现在能买到的这些，笔尖还是铱金的，靠的是仅剩的老库存撑着。

胜利尖的源头要说到1942年，犀飞利出的Triumph系列。那时候圆珠笔开始蚕食钢笔市场，各大厂商都在想办法突围。犀飞利给出的方案是一种全新的笔尖形态：不再是传统的开放尖，而是将整块金属片弯折成圆锥形套筒，把笔舌完全包裹进去，笔尖与笔握之间形成一个流畅的连续曲面。这种设计的初衷，一方面是为了让笔尖更坚固，犀飞利在广告中宣称它"可以带到任何地方"，甚至能垫多层复写纸一次写出三份清晰的拷贝——硬度可见一斑；另一方面，锥形结构让笔尖与笔舌的接触面积大幅增加，墨槽延伸至笔握，供墨比传统设计更加稳定可靠。

胜利尖还有一个容易被忽视的细节：笔尖微微上翘。这个"塌鼻子"造型不是装饰，而是犀飞利工程师反复推敲的结果。上翘的锥形在复写纸上用力书写时不会戳破纸张，同时允许笔尖反面书写细字。早期胜利尖的翘起幅度更大，笔尖也更短更宽，后来随着工艺成熟逐渐收敛，但始终保留了这一独特的结构特征。

在长达五十多年的生产周期里，胜利尖经历了多次演变。最早是14K金片弯曲成形后焊接，接缝处由技工手工打磨抛光。1948年改用无缝管材加工，生产效率大幅提升。1952年犀飞利又推出了钯银材质的胜利尖，用于定位较低端的型号。材质不同，手感也各异——钯银尖极硬，几乎没有弹性；14K金尖同样偏硬，但笔尖厚度摆在那里，写起来有种"硬朗而不失韧性"的独特体验。犀飞利甚至用这种笔尖做过音乐尖，专供书法使用，在收藏市场上动辄拍到数百美元。

胜利尖从1942年一直生产到1998年才正式停产。将近六十年的生命周期，放到整个钢笔史上都是罕见的。但对于大多数国内玩家来说，真正接触胜利尖的途径并不是犀飞利的古董笔，而是永生和幸福厂仿制的"大包尖"。新中国成立后，上海制笔工业通过学习苏联和借鉴欧美技术逐步发展起来，永生笔厂的前身是民国时期创立的商务自来水笔厂，经过多次改组才定型为后来的国营新华金笔厂。据钢笔论坛上的老玩家回忆，幸福厂最早开始仿制犀飞利的胜利尖结构，后来两厂合并，永生系列也就顺理成章地延续了这种笔尖形态。

但仿制不意味着粗糙。有笔友评价70年代的永生233"感觉那可不是一种粗糙的仿制品，甚至是一种超越，用了接近40年了笔还能用，而且笔帽笔身做工精致"。更有意思的是，永生的大包尖还保留了一个"遗迹"——笔舌上那个小小的圆孔和内部的细管。这个结构在老笔友看来是个"莫名其妙的摆设"，但了解犀飞利历史的人一眼就能认出：那是潜艇上墨的呼吸管设计。1952年犀飞利推出的潜艇上墨，通过一根可以伸缩的金属管直接从墨水瓶底部吸墨，笔尖全程不沾墨水，被称为"钢笔史上最复杂的上墨系统"。永生当年连这个结构也一并仿制了，尽管在实际生产中并没有保留潜艇上墨的全部功能，但这个细节足以说明当年的仿制有多么"完整"——甚至连犀飞利广告里那个笔尖微微上翘的"朝天鼻"特征，在永生的大包尖上也被忠实复刻了。

讲回这支601A。永生的大包尖钢笔在历史上出过不少经典型号，最常见的是233、235、236、237等铱金笔，以及永生300、幸福270等14K金笔。这些老笔在二手市场上依然流通，但品相参差，上墨系统也多半年久失修。君来采用库存的老笔尖搭配现代活塞上墨系统，算是用一种"折中方案"让胜利尖重新回到了市场上。笔尖批次不同，出水、弹性、声音可能有点差别。活塞系统容量大，可靠，第一次用建议多吸几次墨水，把空气排干净。笔杆工业感强，重量刚好，握久了不累，就是外观朴实，少了老永生那种温润朴素的工业设计风格。

说到手感，胜利尖的书写体验在整个钢笔谱系里独树一帜。它不像暗尖那样将笔尖深藏，只露出小小一点，也不像明尖那样舒展外露。胜利尖处于两者之间——笔尖完全暴露在外，书写视野开阔，但圆锥形的结构又赋予了它接近暗尖的硬朗支撑。有笔友形容永生300的胜利尖"写字的视野好，进而手感好"，而且"略有弹性"。而犀飞利原版的大号胜利尖，光笔尖重量就接近1克，厚度可见一斑。

我特别喜欢这手感。不是中性笔那种滑到底，也不是软金尖那种细腻回弹，而是中间那点"阻力和反馈"。落笔有实感，行笔有质感，写长笔记或随手画时，笔不会"跑"，像个老朋友陪着你，一笔一划都踏实。用钢笔论坛一位老玩家的话说，"这种硬朗的写感简直算得上写字带风"。放在今天，在动辄追求"滑顺如丝"的书写工具潮流里，这种略带阻尼、需要一点力度的反馈反而成了一种奢侈——它提醒你，写字这件事本身，是可以被感知的。

从五笔到双拼：一场不得不作的告别

2024-06-21T00:00:00Z

五笔字型的源头，要追溯到1978年。王永民在南阳开始研究汉字输入技术，历经五年实验，最终将汉字拆分为130多个基本字根，分布在标准英文键盘的25个字母键上（Z键用作学习键）。1983年8月28日，这个方案通过鉴定，之后又经过两年改进，于1986年定稿并正式推广，史称"86版五笔"。严格说来，1986年秋推出的原始版本叫"86-4.5版"，后来还有个取码规范化的改进版WB-18030（2000年推出），不过用的人寥寥无几。1998年王永民又推出了第二代98版五笔，增补了甫、未、甘、母等整字字根，2008年第三代新世纪版问世，建立新的字根键位体系，可处理27533个简繁汉字，号称五笔的"终极版本"。

五笔输入法的用户总数约2000万至3000万量级，分布极不平衡——86版凭借先发优势占据了绝对主导地位，98版和新世纪版始终未能撼动，五笔社区内部的"版本之争"倒成为一个长期话题。

后来试了仓颉。仓颉由朱邦复于1976年创制，原名"形意检字法"，本意是解决电脑处理汉字的问题——当时英文科技垄断计算机世界，朱邦复试图打破这一局面。1978年，蒋纬国为纪念上古仓颉造字的精神，将其重新定名为"仓颉输入法"。朱邦复深入研究中文字的结构和构成原理，结合电脑逻辑处理的需要，整理出24个仓颉字母，每个字母又关联多个辅助字形，重码率很低。但它的拆字逻辑是为繁体设计的，简体字拆起来总显得支离破碎。1982年，朱邦复登报公开放弃仓颉输入法专利权，推动电脑中文化，这种"开放精神"在输入法史上堪称独一份，但开放归开放，简体用户用它始终隔了一层。

转机出现在百度贴吧。一个老帖子里，有人说了这么一段话："形码输入法原创写作时，效率其实不如声码。它真正的优势是抄稿子——看着纸稿盲打，几乎不用选字。创作时，大脑要把'心里的声音'翻译成字根，反而拖慢思路。"这话像当头一棒，把我从五笔的执念里敲了出来。有心理学研究也佐证了这一点——有研究利用眼动技术考察中小学生的输入过程，发现形码输入的整体速度虽然快于音码，但选字框的信息量是影响速度的主要因素。换句话说，形码的"快"更多体现在选字少、无需中断视觉焦点上，而在思考与输出同步的场景中，形码多了一道"字形翻译"环节，优势并不明显。

于是我开始正视拼音。全拼按键太多，一个"装"字要按六个键，平均每个字四到六下。脑子想完三句，手还在打第一句。双拼就成了自然之选。

双拼的核心很简单：把声母和韵母各压到一个键，两个键一个音节。但同一原理落实到不同方案上，键位分布的差异带来截然不同的手感和跨平台体验。最初我用拼音加加双拼，这个方案规律性强，声韵母按拼音表对称排列，学习门槛很低，来源可以追溯到四通打字机的双拼设计。但我很快发现有些组合指法不顺，比如"追"字的"v+ui"两个键都在左手，打快了左手忙不过来。更致命的是跨平台支持差——搜狗输入法、微软拼音等主流输入法虽然大多预置了拼音加加方案，但手机端支持参差不齐，换台设备就得重新配置。

后来换微软双拼。Windows 原生支持是其最大优势，键位设计来自自然码的改版，最大的争议是把ing放在分号键上，右手小指一压就出来，左右手分工很舒服。分号键的争议一直不小——右手小指频繁伸向分号，有人觉得这样的分布不符合键盘规范，另一些人则觉得多一个键位反而拓宽了韵母分布空间。微软方案的另一特点是跨平台覆盖极好，Windows、macOS、iOS、Android 的主流输入法几乎都内置了这一布局，换任何设备都不用重新学习。

小鹤双拼是很多人的"退烧方案"。它的键位设计比较均衡，左右手负荷分配合理，且支持进阶的"小鹤音形"方案——在双拼基础上附加形码辅助，打字上限更高。但可能是我个人习惯问题，用着总觉得右手小指被架空，节奏上有点拖。

在双拼方案的历史上，还有一个名字绕不过去——自然码。它韵母分配比较合理，左右手相对平衡，由周志农开发，一度非常流行。可惜自然码的作者把大量精力花在防破解上，商业策略失误，最终没能成为各大操作系统的标配。目前市面上大多数双拼方案（包括微软双拼、搜狗双拼）其实都是自然码的改版。

从实践来看，双拼方案之间的迁移成本并不高，挑一个顺手的坚持下去即可。我的最终选择是微软双拼——谈不上最好，但跨平台最省心。

至于五笔在当下的处境，RIME（中州韵输入法引擎） 几乎是唯一在Windows上延续五笔体验的出路。RIME开源免费，高度可定制，Windows版叫"小狼毫"，macOS版叫"鼠须管"，Android叫"同文"，iOS叫"仓输入法"。它支持五笔、双拼、仓颉、注音等几乎所有中文输入方案，理论上可以打磨成完全符合个人习惯的形状。RIME 支持自定义短语和扩展词库——你可以把常用句子设定为短码，也可以导入搜狗词库扩充词汇量。但要做好这些，得熟悉 YAML 格式和 RIME 的配置逻辑。比如要调整候选词个数或中英文切换键，需要新建一个 .custom.yaml 文件，修改后还要重新部署才能生效。有用户调侃："RIME 用一周配置，用一辈子打字。"我不想花这个精力。

从五笔到双拼，更像一场从形到声的妥协与和解。我牺牲了极致的单字盲打精度，换来了更贴思考节奏的流畅——心里默念一句话，手指跟着音节走，不用再经过"字形→字根"的翻译。五笔在创作场景中多一道翻译工序，而在照稿录入时效率最高，这一点贴吧那番话确实说到了根上。也换来了不用总折腾软件的安心：系统更新不怕，换电脑不怕，手机电脑无缝切换。

适合自己的，才是最好的输入法。我偶尔还会怀念五笔那种"打字如写字"的精确度，但回不去了。也不打算回去。

欧美钢笔厂商往事：万宝龙、百利金、水人、派克、犀飞利

2024-05-17T00:00:00Z

汉堡的冬天。1906年。银行家 Claus-Johannes Voss 和工程师 August Eberstein 坐在咖啡馆里，桌上摊着图纸。他们想做一支不漏墨的钢笔。那时候的钢笔，墨水总是从笔尖渗出来，弄脏手指，弄脏纸张。他们想改变这个。

在墨迹斑斓的西方文坛，这些欧美钢笔厂商如古老城堡般屹立，守望着上世纪的荣光与风雨。它们从创新的火种中诞生，伴随两次世界大战与经济风云，铸就了书写永恒的传奇。万宝龙的华贵、百利金的稳健、水人的优雅、派克的可靠、犀飞利的灵动，各有千秋，却共同谱写了一曲墨香交响。

万宝龙1906年于德国汉堡启幕，由银行家与工程师联手，首创内置墨囊的安全笔，奠定奢华基调。其优点在于那份精致工艺，宛若艺术品般优雅耐久；早年价格高企，或让寻常文人稍感遥远，却正因稀贵，更添尊荣。1919年，其笔签署《凡尔赛条约》，见证和平曙光；1924年推出 Meisterstück，意为"大师之作"，从此成为全球最畅销的高端钢笔之一。这支笔之所以成为经典，在于它解决了钢笔的两个核心痛点：一是采用活塞上墨，墨水容量比同时代其他笔大得多；二是笔尖采用 14K 金、经过手工打磨，每一支的书写手感都有细微差别。至今万宝龙仍在生产 Meisterstück，笔尖的形状和尺寸几乎没变——这在日新月异的工业社会里近乎奇迹。重要笔型包括 1909 年首款安全笔 Rouge et Noir（红黑双色，防漏设计）和 1924 年的 Meisterstück 149——巨型金笔，18K 笔尖，雪峰星徽，高端典范。

百利金1838年源于德国墨汁厂，1929年首推活塞填充钢笔，开启文具新纪元。其长处是可靠墨量与耐用身躯，如老友般陪伴不倦；早年专注欧洲，或在美洲稍显低调，却因此更显匠心纯真。1958年 P1 系列革新，引入塑料注塑，助力大众书写；战后复苏，出口全球，奠定"绿鹈鹕"传奇。重要笔型包括 1929 年的 100N（首款活塞笔，绿色条纹，墨水充盈）和 1950 至 1960 年代的 M400/M800——Souverän 系列，14K 金尖，平衡优雅。

水人1883年由 Lewis Edson Waterman 在美国纽约创立，发明"三裂喂墨"系统，首创可靠钢笔。优点显于那份流畅优雅，书写如江河般自然；早期硬橡胶易褪色，或需细心呵护，却正合其古典韵味。20世纪初转向杠杆填充，革新墨水注入；1950年代推出卡匣笔，适应现代节奏。重要笔型包括 1920 年代的 Patrician（奢华硬橡胶笔，金饰华丽）和 1990 年代的 Expert（现代树脂笔身，书写流畅，日常伴侣）。

派克1888年由 George Safford Parker 在美国威斯康星创立，首创"Lucky Curve"喂墨系统，解决漏墨痛点。其优点是可靠耐用，如盾牌般守护书写；早年价格亲民，普及大众，却在高端领域稍显不足，后以 Duofold 系列补足。1921年推出 Duofold，橙色大笔，轰动市场；1940年代"51"系列问世，包尖设计，书写如丝，成为二战后最畅销笔型。关键笔型包括 1921 年的 Duofold（巨型笔，橙色笔身，金尖华丽）和 1941 年的 51（包尖设计，墨水流畅，书写如丝，战后畅销传奇）。

犀飞利1912年由 Walter A. Sheaffer 在美国爱荷华创立，首创"Touchdown"活塞填充系统——用户只需按压笔尾的金属杆，墨水就会被吸入笔身内部的活塞舱。这个设计比当时的杠杆填充更可靠，漏墨概率更低，迅速成为其标志性技术。其优点是灵动创新，设计如翼般轻盈；早年价格中高，受众稍窄，却在收藏家心中赢得独特地位。1920年代推出 Lifetime 系列，终身保修，树立品质信心；1940年代 Triumph 笔尖问世，包尖设计，书写沙沙作响，成为犀飞利标志性创新。重要笔型包括 1920 年代的 Lifetime（终身保修笔，金尖耐用）和 1940 年代的 Triumph（包尖设计，书写沙沙，手感独特）。

万宝龙的华贵、百利金的稳健、水人的优雅、派克的可靠、犀飞利的灵动，共同谱写了上世纪的墨香交响。这些品牌至今仍在生产，虽然市场份额早已被中性笔和键盘蚕食，但每一支老笔背后，都藏着一个时代对书写这件事的认真。

日本钢笔御三家：百乐、白金、写乐的百年匠心

2024-04-16T00:00:00Z

日本的钢笔工艺如一曲细腻的和歌，悄然绽放百年光华。御三家——百乐、白金、写乐——犹如三位百年匠人，各自守着一隅匠心，却共同绘就了岛国文具的华章。它们从明治末年的舶来之风中崛起，历经战火洗礼与技术革新，铸就了不朽的书写传奇。

百乐的前身可溯至1915年，工程教授 Ryosuke Namiki 与 Masao Wada 的携手，初衷仅为铸就不锈钢笔尖，打破西方垄断。1918年正式创厂于东京，名为 Namiki Manufacturing Company，后更名 Pilot，寓意"领航者"。早年产品以金笔尖为主，出口欧美，奠定国际声誉。二战期间，工厂转产军需，却在战后迅速复苏，1950年代推出批量不锈钢笔尖，推动本土工业腾飞。

1963年，百乐首创 Capless 可伸缩钢笔，旋钮一转，笔尖隐现，无需笔帽，获巴黎国际礼品展"最推荐产品奖"，革新书写便利。这支笔最初是为经常需要在旅途中签字的商务人士设计的——不用拧开笔帽、旋紧笔帽，单手就能完成书写，尤其适合医生、快递员、税务员等需要频繁用笔的职业。1970至1990年间，Capless 系列迭代，从蚀刻款到多面体设计，技术跃进，彰显日本精密之美。1980年代，Custom 系列问世，传承百年工艺，定位高端定制。重要笔型包括 Capless（1963年，旋钮机制，笔身纤细，至今仍是旅行者的挚友）、Custom 74（1970年代，入门金笔，14K 笔尖柔韧，树脂笔身轻盈）和 Custom 823（1980年代，真空吸墨设计，21K 金尖，墨量充沛，适合长篇书写）。

白金的起源似一阕清幽小调，1919年创始人 Shunichi Nakata 于东京启业，初售进口笔，后自制 Champion、Piiton 等款，出口海外。1924年建立中屋制作所，专注笔尖锻造，战时转产军工，1950年代复苏，强调"纯净书写"。1956年推出全球首款卡匣式钢笔，摒弃吸墨瓶，书写更卫生便捷。1965年发明"敲击式"可点击钢笔，1967年 Platinum Platinum 问世，首用铂金涂层笔尖，抗腐蚀耐久。1993年限量款与 Hayakawa 机械铅笔同步上市，1994年 President 系列登场，标志中高端转型。重要笔型包括 Honest 60（1950年代，首款卡匣笔，简约金属身）、3776 Century（1970年代，14K 金尖，活塞上墨，"3776"寓意富士山高度）和 President（1994年，高端商务笔，18K 金尖，平衡舒适）。

写乐的故事始于1911年，创始人 Kyogoro Sakata 于大阪启业，初名 Sailor Pen，寓意"航海者"，灵感源自一位英国水手赠送的钢笔。早年产品以金属笔尖为主，出口东南亚，奠定海外根基。二战期间工厂转产军需，战后复苏，1950年代推出不锈钢笔尖，技术革新。1960年代，写乐推出 Profit 系列，21K 金尖，书写流畅，定位高端。1970年代，长刀研笔尖（Naginata Togi）问世，独特打磨方式使笔尖正面呈弧形切削状，侧面则保留了传统刀刃般的锐角。这种形状使得书写时笔尖会随着运笔方向自然变形——横画细、竖画粗，转折处还能写出类似毛笔的"锋"，尤其适合写汉字时追求笔画粗细变化的书法爱好者。写乐因此被国内的钢笔收藏家称为"书法笔之王"。1980年代，Professional Gear 系列登场，21K 金尖，笔身坚固。重要笔型包括 Profit（1960年代，21K 金尖，活塞上墨）、长刀研（1970年代，独特打磨，书写如书法）和 Professional Gear（1980年代，21K 金尖，树脂笔身，坚固耐用）。

百乐的创新、白金的纯净、写乐的匠心，共同绘就了日本钢笔的百年华章。它们从舶来之风中崛起，历经战火与革新，铸就了书写永恒的传奇。如今在日本的文具店里，这三家的产品依然并肩陈列——从几百日元的平价钢笔到数十万日元的高级莳绘，各自占据着不同的货架，继续书写着下一个百年。

Jekyll 与 Chirpy 主题：一位新手博客的试错史

2024-02-03T00:00:00Z

事实上，我最初使用的 Jekyll 主题是 Academic Pages。（搭建过程中参考了这篇文章，不过这位大佬似乎有两个 GitHub 账号，今年年初我曾问过他，他的项目大多在 wanng-ide 中，而 wangjunjie-ai 则是用来搭建 Pages 的。）

为何选择这个主题？因为它预设的配置相当全面，我只管写文章便是。毕竟这是一个"学术"个人主页，设计初衷便是减少折腾、直奔主题。

然而，我不过是个普通博主。为了将这个学术博客改造成普通博客，我费了不少功夫，最终还是放弃了——这个主题的限制实在太多。

后来很长一段时间，我离开了 GitHub，自然也不再使用 GitHub Pages，转而投向动态博客的怀抱（用 Halo 搭建）。

这几天突然萌生了回归静态博客、做一个国际博客的念头，于是重拾 Jekyll。主题呢？半年前寻觅 GitHub Pages 模板时，我就注意到了 Chirpy——简洁干净的三栏式设计，深得我心。于是今年便直接采用了。去年没用，是因为当时想找的是开箱即用的模板。

用 Chirpy 碰到的第一颗钉子，是 URL 生成。这是一个国际博客，文章有多个语言版本，需要在 URL 中通过语言标签来区分。有些双语文章使用的还不是标准的语言标签，比如这篇文章的 lang 标签就是 en-zh。

怎么办？我尝试更改 Jekyll 的 _config.yml 文件，却导致生成失败。我尝试安装 Gem 包里的 Jekyll 多语言 URL 支持插件，但版本都太老了。于是只好自己写了个插件出来：

# _plugins/auto-permalink.rb

Jekyll::Hooks.register :site, :pre_render do |site|
  site.posts.docs.each do |post|
    begin
      lang = post.data['lang'] || 'en'
      lang = lang.to_s.strip
      lang = 'en' if lang.empty?
      
      slug = post.data['slug']
      if slug.nil? || slug.to_s.strip.empty?
        basename = post.basename_without_ext.to_s
        slug = basename.sub(/^\d{4}-\d{2}-\d{2}-/, '')
      end
      
      slug = slug.to_s.strip
      slug = slug.gsub(/[^a-zA-Z0-9\-_]/, '-')
      slug = slug.gsub(/-+/, '-')
      slug = slug.gsub(/^-|-$/, '')
      slug = 'untitled' if slug.empty?
      
      permalink = "/posts/#{lang}/#{slug}/"
      post.data['permalink'] = permalink
      
    rescue => e
      Jekyll.logger.warn "Auto-permalink:", "Error processing post: #{e.message}"
      post.data['permalink'] = "/posts/untitled/"
    end
  end
end

URL 的问题解决了，第二个问题是字体。

我在网上查到的许多覆盖方案都不适用于 Gem 包里的主题。最后的解决方案是在 _includes/head.html 里添加以下代码：

<!-- Custom Font -->
<link href="https://hanzi.itedev.com/fonts/Source+Han+Sans+VF/result.css" rel="stylesheet">
<style>
  .content {
    font-family: 'Source Han Sans VF', 'Microsoft YaHei', 'PingFang SC', 'MiSans', sans-serif !important;
  }
</style>

hanzi 千字网 CDN 是我自己构建的字体 CDN，大家可以去网站首页或从我的 Codeberg 仓库了解这个项目。

第三个问题是隐藏文章。最初 MiniMax 告诉我直接在 tags 里添加 hidden 就行，然后我发现没用。我的想法是开发一个插件，但无论怎么修改 Ruby 代码，最后的结果永远是无法从直链访问文章——文章被直接删除了，而非隐藏。

后来我发现，实际上 Chirpy 内置了在首页隐藏文章的功能。不是在 tags 里添加，而是在 front matter 中添加 hidden: true 就行。害得我绕了个大弯——根本不用改配置，Chirpy 本来就有这个功能。

中国古董钢笔厂商：英雄、永生、金星与鸵鸟墨水的时代故事

2023-03-15T00:00:00Z

上世纪。上海西藏南路的厂房里，机器轰鸣。工人穿着蓝色工装，手指沾满机油。钢笔尖在冲压机下成型，发出清脆的金属声。这是1931年的上海，华孚金笔厂刚刚起步。

中国钢笔产业从民族实业的萌芽起步，逐步成长为书写共和国历史的工具。这些厂商不仅生产了日常文具，还见证了国家从动荡到复兴的进程。英雄、永生、金星作为上海与北京的代表性钢笔厂，凭借技术创新和品质追求，填补了进口品牌的空白；天津鸵鸟墨水厂则以墨汁供应支撑了书写生态。

1931年，浙江奉化人周荆庭投资1.5万银元，创办华孚金笔厂。目的只有一个：打破"中国人生产不了钢笔"的垄断局面。那时候，上海街头的知识分子手里握着的，大多是派克、犀飞利这样的洋货。一支钢笔的价格抵得上普通工人半个月的工资。周荆庭想做一支中国人自己的笔。厂址初设于上海西藏南路，产品以新民牌金笔为主，价格亲民，书写顺滑，主要服务中学生和知识分子。抗日战争时期，工厂迁至重庆维持生产；1949年后迁回上海，并在1950年代移至桃浦工业区。

1958年"大跃进"期间，华孚金笔厂更名为英雄金笔厂，提出"英雄赶派克、为国争光"的口号。这是一项重大技术攻关：工厂用9个月时间研制"英雄100型"金笔，在12项指标中11项赶超美国派克51，包括笔尖毛坯7道连冲和注塑群控工艺。那时候的工人三班倒，睡在车间里。图纸铺在地上，计算尺和算盘响个不停。九个月后，英雄100型诞生了。这支笔后来被命名为"英雄100型"，其中"100"既是对派克51的致敬，也暗含"百分之一百赶超"的野心。此后，英雄钢笔迅速扩张，1960年代中期正式定名"英雄"，并开始出口60多个国家和地区。1980年代中后期，产品结构调整向中高档倾斜，总资产超7亿元，市场份额近垄断。但1990年代初，受政府干预，与永生厂合并，并推行多元化投资，导致资金链紧张。

英雄钢笔参与了多项国家大事：1984年4月13日，邓小平用英雄笔签署《中英关于香港问题的联合声明》；1997年香港回归、1999年澳门回归、上海合作组织成立、中国加入WTO等文件，也由其签署。重要笔型包括1958年的英雄100型（大包头金笔，笔帽笔尾双珠设计），1960年代的英雄616型（经典学生笔，塑料外壳，耐用经济），以及1980年代的英雄800型（中高档升级版，树脂外壳）。

永生钢笔制造厂成立于1940年代初，由钮永集创办于上海，初期以组装派克公司半成品起步，产品定位中档文具。厂址位于上海罗浮路，1958年并入5家电镀厂和新明钢笔厂，扩大产能。1960年，大陆金笔厂转业，其大包头金笔生产线划归永生厂。1963年改名为地方国营新华金笔厂，1960至1970年代完成多项技术改造，如不锈钢激光焊缝机和多功位冲制，从日本、瑞士等国引进设备。这些创新提升了笔尖精度和产量，但未有大规模出口记录。1990年代初，与英雄厂合并，资金统一，但多元化策略导致经营压力。1999年，原厂倒闭，品牌被英雄实业（非英雄集团）收购。现今市售的"永生"钢笔与原厂已无任何技术传承关系——新生产者只是租用了一个曾经响亮的名字，而当年永生厂的技术积累、工艺标准、工匠团队，都随着倒闭风流散各地。重要笔型包括永生233型（1965年起，金属笔身，网格状外观）、永生235型（1960年代，金色网格金属身，大包头尖）和永生727型（1970年代，暗尖设计，活塞上墨）。

金星钢笔厂成立于1930年代的北京，由民族资本家创办，初名"金星金笔厂"，厂址位于北京西城区。1950年代并入地方国营体系，成为北京文具工业的主力。其产品以实用为主，价格亲民，服务北方学生与公务员群体。1960至1970年代，技术改造有限，依赖上海技术支援，产量稳定但创新不足。1980年代后期，受市场开放冲击，经营困难，1990年代初停产，品牌淡出市场。重要笔型包括金星26型（1950年代，经典学生笔，塑料笔身）和金星28型（1960年代，金属笔身，暗尖设计）。

天津鸵鸟墨水厂成立于1920年代，初为私营墨汁作坊，1950年代并入地方国营，成为北方墨水供应主力。其产品以碳素墨水为主，配合钢笔使用，书写流畅，价格低廉。1960至1980年代，技术稳定，产量持续，支撑了英雄、永生等钢笔的书写生态。1990年代后期，受圆珠笔与中性笔冲击，市场份额下降，但品牌仍存，延续传统墨水生产。重要产品包括鸵鸟562型墨水（1960年代，碳素墨水，不堵笔）和鸵鸟高级墨水（1980年代，色泽更深，适合档案书写）。

上世纪的中国钢笔厂商，从民族实业起步，历经战火与复兴，铸就了书写历史的工具。英雄赶超派克、永生坚守实用、金星低调服务、鸵鸟支撑墨水，共同构成了一个完整的文具生态。如今在文具店里偶尔还能看到英雄616——几块钱一支，笔尖依然顺滑。只是很少有人知道，这支貌不惊人的小笔身后，承载着几代工人的手艺与梦想。