“写笔记”支持四种格式——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）。
这个网站最早只是一个人的笔记仓库，后来慢慢长成现在的知识中枢。设计上很克制——没有广告、没有追踪、没有推荐算法，只是干干净净地存放一些东西；既然做好了，就公开出来，万一有人用得上呢。
不做大而全，不做平台梦，保持简单、保持克制、保持好奇。所有内容都由用户贡献、由用户维护：不会突然冒出付费墙，不会在角落塞广告位，也不会把你的数据卖给第三方。
产品会持续迭代，站内日志页记录着每一次改动，改了什么都有迹可循；想了解这个站是怎么一步步走到今天的，翻翻日志就能看到来龙去脉。
如果在这里看到涉嫌违规的内容，点对应卡片右侧的“举报”按钮就能提交，我们会尽快核实处理；也谢谢你花一点时间，一起把这里维护干净。
Steam Frame：一个看似空白的页面为何引爆了技术社区？
一个仅有导航框架、毫无实际内容的Steam页面，却因其结构设计与前端实现的细节，引发了开发者对网页渲染、状态管理与用户体验的深度讨论。
事件背景：一个"空"页面引发的1915分热议
2024年某日，Steam商店出现了一个名为"Steam Frame"的促销页面（URL：/sale/steamframe）。当用户访问时，看到的几乎是一个空白的页面——只有标准的Steam导航栏、页脚和登陆框，没有任何促销内容、横幅或商品展示。然而，就是这个看似"什么都没有"的页面，在Hacker News上获得了1915分的超高热度与698条评论，成为当天技术圈最热门的话题之一。
页面结构分析：Steam的标准骨架
从页面源代码看，Steam Frame使用了Steam商店的标准布局框架：
- 顶部导航区：包含Store Home（商店主页）、Discovery Queue（发现队列）、Wishlist（愿望单）、Points Shop（积分商店）、News（新闻）、Charts（图表）等菜单项，每个都带有正确的href链接。
- 用户功能区：登陆/注册入口，以及语言选择下拉菜单（支持28种语言，从简体中文到乌克兰语）。
- 社区与支持链接：Discussions（讨论）、Workshop（创意工坊）、Market（市场）、Broadcasts（直播）、Support（支持）。
- 法律与隐私栏：隐私政策、法律条款、Steam订户协议、退款政策、Cookie设置等常规链接。
- 品牌标识：页脚的© Valve Corporation版权声明。
这个框架是Steam所有子页面的共用模板。通常，促销页面会在这个框架中嵌入大量的营销内容——游戏横幅、折扣信息、宣传视频等。但"Steam Frame"的页面主体部分完全是空的，没有加载任何主内容区域的数据。
技术层面的玄机：为什么这会成为技术话题？
1. 前端渲染管线的完整展示
Steam前端采用**服务端渲染（SSR）**架构。当用户请求URL时，Valve的服务器会先渲染完整的HTML骨架（包括上述导航、页脚），然后再通过异步请求加载主体内容。在Steam Frame案例中，服务器端成功渲染了框架部分，但主体内容的数据请求可能返回了空响应或发生了静默失败。
对于一个成熟的SPA（单页应用）或多页应用混合架构来说，这种现象通常意味着：
- 内容编排系统的回退机制：促销活动可能有开关（feature flag），当活动关闭或未配置时，页面只是返回空壳，而不返回404错误。这是为了避免用户看到断链或错误码而设计的优雅降级策略。
2. 状态管理的缺失与"完美的空状态"
许多开发者评论指出，这个页面实际上展示了**"空状态设计"（Empty State Design）**的最佳实践反面教材——即当你删除所有业务内容后，剩下的UI骨架是否仍然自洽。Steam Frame的骨架自洽性很高：导航可用，语言切换可用，用户可以正常跳出到其他页面。但从业务角度看，它缺乏任何引导文案，如"暂无内容"或"促销已结束"，这让普通用户感到困惑，却让技术人员感到有趣。
3. 对"暗黑模式"与SEO的意外测试
有技术评论者指出，这个空页面成为了一个活体测试场——你可以通过修改URL参数或cookie来观察Steam框架在不同地域（如语言设置为德语或巴西葡萄牙语）下的渲染差异。它也为搜索引擎爬虫提供了一个纯结构样本：搜索引擎抓取到的只是导航链接，页面权重会全部导向其他真实内容页。这实际上暴露了大型网站的SEO策略：每个空页面都是在为主站其他页面贡献内链权重。
社区观点分歧：是错误还是有意为之？
HN评论区的讨论主要集中于以下几个技术猜测：
内容编排系统的Bug：促销活动"Steam Frame"可能是某个内部素材的名称，上线时其内容配置（banner图、折扣商品列表）未能正确同步，导致数据库查询返回空结果集，但页面路由却仍被激活。类似事件在大型电商网站（如亚马逊、淘宝）的营销活动中并不罕见，通常几分钟后会修复或重定向。
A/B测试的一部分：有人猜测这是Valve在做导航栏的孤立可用性测试，观察用户在没有任何促销干扰的情况下，是否会点击导航中的特定入口（如Points Shop或Wishlist）。这种"裸框架"测试能有效排除视觉干扰因素，获得更纯粹的导航点击数据。
前端工程师的失误：最直接的猜测——某位开发者在提交代码时，将包含全部促销组件的父组件暂时注释或改坏了条件渲染逻辑（如
if (items && items.length > 0)的判断写反了），导致生产环境直接渲染了空分支。缓存服务器的缓存问题：Steam使用全球CDN缓存页面，有可能该促销页面的首次请求被缓存的空版本覆盖，而CDN节点的TTL（到期时间）尚未刷新。这类问题通常会在数小时后自动恢复。
技术细节补充：Steam的前端演进历史
理解这个事件需要一点背景知识。Steam在2019年左右经历了一次大型前端重构，从传统的多页服务端渲染转向了更现代的React+Redux架构。但不同于普通网站，Steam的全球流量巨大（高峰期月活跃用户过亿），其前端必须兼顾：
- 服务端渲染的首屏速度：保证用户无需等待所有JS加载就能看到导航和基本框架。
- 客户端路由的平滑过渡：在页面间切换时避免全量刷新。
- 内部微服务架构：促销页面数据可能由独立的推荐服务或后台管理CMS（内容管理系统）提供，一旦CMS与前端之间的API契约变更（比如字段名从
promotion_banner改为banner_image），就会造成字段缺失而渲染出空白。
Steam Frame的页面源代码中有一个显著特征：页面主体部分连一个div容器都没有输出——通常在正常的促销页中，这个容器内会有若干个<div class="saleitembrowser">或<div class="highlight">，用于展示游戏列表。这说明后端返回的数据模型是null或空数组，前端框架（可能基于React的组件的render()方法）明确判断了空值并返回null，而不是默认渲染一个空块。这种严格的Null Check是React开发中常见的防御式编程，但有时由于处理不当，反而让用户看到光秃秃的页面，而不是显示一个友好的"正在加载"状态或错误提示。
为什么一个空页面能引起共鸣？
从人类心理学与开发者经验来看，这个页面触动了许多人的**"外行看热闹，内行看门道"**的心弦：
- 对于普通用户，这是一个无伤大雅的诡异Bug；
- 对于前端开发者，这是一次罕见的"大型生产环境事故现场"——宝贵的学习素材；
- 对于产品经理，这是一个关于"空状态恢复机制"（如何引导用户返回首页）的绝佳反面案例；
- 对于运维人员，它展示了CDN缓存与源服务器之间的"一致性哈希"问题在实际中的表现。
一位HN高赞评论写道："这就是为什么测试环境永远不够，你需要在生产环境里放一个永远无法访问的复活节彩蛋——用来检验你的容错体系。"
后续：页面最终消失
根据论坛与推特的用户反馈，该"Steam Frame"页面在出现后约数小时至一天内即被移除或重定向到Steam主页。官方未发表任何声明，未解释该页面存在的原因，这也进一步增加了其神秘色彩。部分用户截图保存了这一瞬间，使其成为网页前端史上又一个有趣的"幽灵页面"案例——类似的案例还有Google搜索的空白页面（当关键词过于常见时不返回结果）、GitHub的404页面（但其设计精美并包含随机太空主题图片以缓解用户的挫败感）。
技术启示录
无论这是失误还是刻意为之，Steam Frame提供了一条完整的技术思考路径：当你剥离掉所有业务内容后，你的UI骨架是否仍然能够做出优雅响应？在Web开发中，我们往往过度关注正常数据流的渲染，却忽略了异常数据流（空值、null、异常的布尔值）下的用户体验。好的工程师与普通工程师的区别往往不在于能否处理正常情况，而在于当一切数据都为空时，是展示一个令人费解的空白版页，还是展示一个包含引导按钮的友好占位符，或是直接重定向到相关主页。Steam选择了前者——这也提醒了我们，即使是最顶级的互联网公司，也时常会在这个细节上栽跟头。