笔记
0工具
0此页用于记录用户反馈问题后的每一次改进
关于
“写笔记”支持四种格式——Word 文档、Excel 表格、Markdown、纯文本，起稿或二次编辑时都能随时切换，同一篇笔记想用哪种形态来记，都由你说了算。
md、txt、csv、json 这类纯文本则原样载入，不做多余加工。拿一张现成的表倒进来、改几笔、再导出去，等于白用一台免费的格式转换器。
要带走就在右上角点“下载”，可导出 PDF、Word、Markdown、Excel、TXT 等格式；列表卡片“⋯”菜单里，也有同样的下载入口。
在“工具”页点“＋ 上传工具”即可发布：填好名称与链接，再用 Markdown 把使用方法写清楚——能解决什么问题、怎么装、怎么用，比堆介绍实在。
要分发安装包就一并上传压缩包（ZIP、RAR、7Z、TAR.GZ，最大 35MB），别人在详情页一键下载；只放链接不带附件也可以。
工具按大家的收藏热度排序，好用的自然会被顶上来。发布后可在详情页或卡片菜单里编辑、下架。
写笔记时勾上“隐藏”，这篇就只存在于你自己的账号里：不进列表、不进搜索、不上首页精选，也不会出现在任何公开的页面，链接发给别人同样打不开。
适合放密码、草稿、日记这类只给自己看的内容；想公开，去“发布”打开它，把“隐藏”的勾去掉再保存，之后编辑会默认保持原状态，不会悄悄变回公开。
不想公开、只想临时给人看：点“分享”生成一条带密码和有效期的链接，到期自动失效，你也能随时撤销。
你的内容会同时保存在多个副本上，系统定期做备份与完整性校验，再配合异地容灾机制：就算某台机器出问题，数据也不会丢，可以长期放心存放；特别重要的资料，仍建议你另外再留一份备份。
全站跑在容器化、模块化的现代架构上，更新、部署、回滚都很快，扩展性和稳定性都按长期运营的标准来设计（Built for reliability, designed to scale）。
这个网站最早只是一个人的笔记仓库，后来慢慢长成现在的知识中枢。设计上很克制——没有广告、没有追踪、没有推荐算法，只是干干净净地存放一些东西；既然做好了，就公开出来，万一有人用得上呢。
不做大而全，不做平台梦，保持简单、保持克制、保持好奇。所有内容都由用户贡献、由用户维护：不会突然冒出付费墙，不会在角落塞广告位，也不会把你的数据卖给第三方。
产品会持续迭代，站内日志页记录着每一次改动，改了什么都有迹可循；想了解这个站是怎么一步步走到今天的，翻翻日志就能看到来龙去脉。
如果在这里看到涉嫌违规的内容，点对应卡片右侧的“举报”按钮就能提交，我们会尽快核实处理；也谢谢你花一点时间，一起把这里维护干净。
趋势
Ghostty 告别 GitHub：一位 18 年老用户的决裂与反思
本文作者 Mitchell Hashimoto 因 GitHub 频繁故障影响工作，宣布其开源项目 Ghostty 将离开 GitHub，并分享了对这个陪伴他 18 年平台的爱恨交织的告别与迁移计划。
写在前面
2026 年 4 月 28 日，HashiCorp 联合创始人、Vagrant 作者、Ghostty 终端模拟器作者 Mitchell Hashimoto 在个人博客上发表了一篇题为 "Ghostty Is Leaving GitHub" 的文章，宣布其主导的开源项目 Ghostty 将正式迁移出 GitHub。这篇文章在 Hacker News 上引发了超过 3500 分的热度与上千条评论，不仅仅因为这是一个重量级开源项目的重大基础设施决策，更因为它是一封写给一个时代的情书与决裂书。
Mitchell 在开篇便坦言："写下这些让我感到一种不理性的悲伤，但 Ghostty 将离开 GitHub。"
18 年：一个时代的数据与记忆
Mitchell 是 GitHub 的第 1299 号用户，注册于 2008 年 2 月。从那时起，他几乎每天都会打开 GitHub，每天多次，持续超过 18 年——这占据了他人生的一半以上。他坦言，即使是在最艰难的时刻，GitHub 都是他的避风港：
- 经历痛苦分手时，他沉浸在 GitHub 上的开源工作中；
- 大学凌晨 4 点，当所有人都沉睡时，他会提交一次 commit；
- 度蜜月时，趁妻子还在睡觉，他打开 GitHub；
- 度假时，他的书签里满是想要研究的 GitHub 项目——不仅仅是源代码，还包括开源流程、其他维护者如何应对困难局面等。
他甚至透露，自己最初创建 Vagrant（他的第一个成功开源项目）的很大一部分原因，是希望借此获得 GitHub 的工作机会。在他 20 岁第一次公开演讲 Vagrant 时，他开玩笑说："也许 GitHub 会因为这个项目而雇用我！"GitHub 曾是他的梦想之地，他从未在那里工作过，但那里是他最想待的地方。
从热爱到愤怒：日常的故障与累积的失望
然而，这份长达 18 年的热爱最近变成了公开的批评与愤怒。Mitchell 承认自己最近对 GitHub 的批评非常严厉，甚至伤害了一些人的感情。他说："因为 GitHub 每天都在让我失望，而且这种失望是个人化的——不理性地个人化。我爱 GitHub 超过一个人应该爱一个东西的程度，而我对它感到愤怒。"
最令人震惊的数据来自他过去一个月的个人记录：他在日记中每天标记一个 "X"，代表 GitHub 故障对他工作产生了负面影响。结果几乎每天都有一个 X。
就在他写这篇文章的当天，由于 GitHub Actions 的一次故障，他大约有 2 小时无法进行任何 PR 审查。他写道："如果一个平台每天让你被阻塞数小时，它就不再适合严肃的工作了。"
核心矛盾：不是 Git，而是围绕 Git 的基础设施
Mitchell 特别回应了那些会说 "Git 是分布式的，你怕什么？" 的人。他指出，问题从来不在 Git 本身，而是我们依赖的围绕 Git 的基础设施：
- Issues（问题追踪）
- Pull Requests（代码审查）
- Actions（CI/CD）
这些服务是 GitHub 生态的核心，也是日常开发工作流中不可回避的环节。当这些服务频繁宕机时，即使代码仓库本身是分布式的，你的工作流依然会被完全阻塞。
迁移计划：渐进式去依赖
Mitchell 明确表示，Ghostty 项目将离开 GitHub，但这不是一蹴而就的：
- 保持只读镜像：他们计划在 GitHub 当前 URL 上保留一个只读镜像，方便历史访问。
- 渐进式迁移：团队已经制定了一个尽可能增量的计划，逐步移除对 GitHub 的所有依赖。
- 多提供商讨论：目前正在与多个商业和 FOSS（自由和开源软件）提供商进行讨论，尚未确定最终去向。
- 个人项目暂留：Mitchell 的个人项目和其他工作暂时仍会留在 GitHub，但未来会视情况而定。
他强调，Ghostty 是维护者和开源社区受 GitHub 故障影响最大的项目，因此这次迁移以 Ghostty 为起点。
脚注中的关键澄清
在文章的脚注中，Mitchell 澄清了几个重要细节：
- 这篇文章的发布时间与 2026 年 4 月 27 日的大规模故障纯属巧合。团队讨论和制定离开 GitHub 的计划已经进行了数月，文章也是一周多前写好的，最终决定本周才做出。
- 文中所提到的当天故障并非 4 月 27 日那次大规模 Elasticsearch 故障，而是另一次独立的 Actions 故障，因为文章写于那次大故障之前一周。
深层思考：开源基础设施的单点依赖问题
这篇文章引发了关于开源生态对单一商业平台过度依赖的广泛讨论。GitHub 作为全球最大的代码托管平台，已经成为开源世界的默认基础设施。然而，当这种基础设施频繁不稳定时，整个开源生态的生产力都会受到影响。
Mitchell 的离开决定，不仅仅是一个项目的技术选型，更是对这种单点依赖模式的一种反抗。他的经历——从 18 年的深度热爱到每日的愤怒与失望——反映了许多长期依赖 GitHub 的开发者的共同心声。
结语
"我想在那里，但它不想要我在那里。我想完成工作，但它不让我完成工作。我想发布软件，但它不让我发布软件。"
这是一个令人唏嘘的告别。Mitchell 表示，他愿意有一天回来，但前提是 GitHub 能展现出真正的改进，而不是空头承诺。
对于开源社区而言，Ghostty 的离开可能只是一个开始——当越来越多重量级项目开始重新评估对 GitHub 的依赖时，整个开源基础设施的格局或许将迎来新的变化。