工具与资源tonsky.me
该升级你的显示器了
Time to Upgrade Your Monitor
2020 — 2022，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这篇文章讨论开发者为何应考虑升级到高分辨率（高 DPI）显示器，重点分析字体渲染清晰度、系统缩放设置以及不同操作系统下的显示效果差异。作者观点鲜明，认为高像素密度能显著改善编码时的文字观感，但也因此引发了不少关于“是否真的必要”的争论。
为什么经久不衰：显示器与字体渲染是开发者每天面对的实际体验问题，文章观点鲜明且技术细节具体，多年后仍能引发关于工具投入与效率的理性讨论。
HN 评论精选
反对“开发者必须上 4K”的论调，认为 1080p 对很多人足够，工具偏好因人而异。
技术细节都没错（至少在我看来是这样），但观点太强加了。不，你不需要 4K 显示器来做软件开发。有人可能喜欢，有人不需要。这听起来就像当年 Jeff Atwood 带起的那股风潮：如果你没有三块外接显示器，你的配置就不合格，你该感到羞耻。不，完全不是。我认识的最好的开发者用 1366x768 的破笔记本写代码，也不觉得是障碍。1080p 对我来说够用了，我喜欢它渲染字体的方式。
the_af查看英文原文
The technical details are all right (or seem right to me, anyway), but this is too opinionated for my liking. No, you do not need a 4K monitor for software development. Some people might like them, some won't. [edit/clarification: someone rightfully pointed out that nobody will actively dislike a 4K monitor. I was unclear here: I meant "some people won't need them" more than "dislike them"] This sounds like when Jeff Atwood started that fad that if you didn't have three external monitors (yes, three) then your setup was suboptimal and you should be ashamed of yourself. No. Just no. The best developers I've known wrote code with tiny laptops with poor 1366x768 displays. They didn't think it was an impediment. Now I'm typing this on one of these displays, and it's terrible and I hate it (I usually use an external 1080p monitor), but it's also no big deal. A 1080p monitor is enough for me. I don't need a 4K monitor. I like how it renders the font. We can argue all day about clear font rendering techniques and whatnot, but if it looks good enough for me and many others, why bother?
工具需求随职业阶段不断变化，不存在一劳永逸的黄金配置。
我发现自己的工具演进之旅很有意思。刚入行时编码很慢，我担心的是语言怎么工作之类的事，根本顾不上文本编辑器，更别说显示器。经验多了以后，新手问题消失，更高层的问题浮现，于是我开始痴迷编辑器、快捷键，甚至多显示器加竖屏。然后进入极简阶段，我烦透了花大量时间维护工具而不是使用工具，于是几乎全砍掉，只留一个大显示器和 VSCode。现在我在想：“到底是谁每天写那么多代码，以至于这些事重要？”因为读写代码大概只占我工作的 35% 了。我当前需要优化的是读写人类文本。我的结论是：需求会继续变化，我不相信存在某种“收敛”的黄金配置。
Waterluvian查看英文原文
I've found my journey through tooling evolution to be fascinating (to me at least). When I was new and coding was slow, my worries were about so many other things (like how the language even worked) than even what text editor I used, let alone the monitor. As I became experienced, a lot of newbie problems went away and the next topmost problems emerged, leading to be obsessing over text editor, shortcuts, and even a multi-monitor setup with a vertical monitor. Then went through a minimalism phase where I was annoyed by how much time I was spending maintaining my tools rather than using them, so gone went almost all of that. Just one giant monitor and VSCode for better or worse (mainly because it does all six languages I use well enough). I'm now at a phase of thinking, "who are all these people who do so much coding in a day that these things matter?" because reading and writing code is maybe.... 35% of my job now? What I need to optimize for is reading/writing human text. And that's where I currently am: figuring out how to optimize writing documentation/design/architecture docs, given how awful making and maintaining a sequence or block diagram is currently. My conclusion so far is that I expect my needs to continue to mutate. I do not believe they are "converging" and do not believe there is any sort of golden setup I will one day discover.
macOS 的字形膨胀让用户习惯更粗的字重，并导致网页设计在其他系统上显得过细。
关于字体平滑，我猜这是 macOS 的字形膨胀（glyph dilation）。pcwalton 逆向工程过它以便在 Pathfinder 里复现，结论是膨胀量为 min(vec2(0.3px), vec2(0.015125, 0.0121) * S)，其中 S 是像素字号。问题是人们会习惯 macOS 的字体渲染，于是（a）不想关掉它，因为跟习惯不同；（b）开始为它做设计。我确信这是很多网站正文用 300 字重而不是 400 的重要原因——macOS 会把它加粗所以还凑合，而其他遵守字体设定的系统上用户就看到令人不适的细字。
chrismorgan查看英文原文
Concerning the smoothing, I presume this is macOS’s glyph dilation. pcwalton reverse engineered it in order to replicate it in Pathfinder (so that it can render text exactly like Core Text does), concluding that the glyph dilation is “min(vec2(0.3px), vec2(0.015125, 0.0121) * S) where S is the font size in px” (https://twitter.com/pcwalton/status/918991457532354560). Fun times. Trouble is, people then get used to macOS’s font rendering, so that (a) they don’t want to turn it off, because it’s different from what they’re used to, and (b) start designing for it. I’m convinced this is a large part of the reason why people deploy so many websites with body text at weight 300 rather than 400, because macOS makes that tolerable because it makes it bolder. Meanwhile people using other operating systems that obey what the font said are left with unpleasantly thin text.
质疑高 DPI 论证方法，认为 4K 开 2x 缩放会损失屏幕空间，清晰度提升未必值得。
作者支持高 DPI 的论证没有说服力。把东西放大 24 倍当然会模糊，但这不代表你真的需要或想要那么高的像素密度。同样的论证技巧可以用来鼓吹 8K/16K 显示器。奇怪的是作者提到 ClearType，但在结论对比时完全忽略了它。如果他把 ClearType 渲染的文字放大（从而使子像素渲染变得无意义），反而是在人为让低 DPI 显得更糟。他还提出用 4K 开 2x 缩放，这很令人费解——那意味着你的 4K 显示器和 1080p 拥有同样的屏幕空间，相比 1440p 的低 DPI 显示器减少了 43% 的面积。我同意那样缩放可能更好看，但无法想象稍好的文字/缩放能弥补屏幕面积的损失。
gruez查看英文原文
The author's argument for high dpi is unconvincing. I mean, if you magnify something by 24x of course it's going to look blurry. That doesn't mean that you actually need/want that high pixel density. You can use the same argument technique to argue for 8k/16k displays. It's also strange how the author mentions that cleartype is a thing, but for the conclusion comparison he ignores it entirely. If anything, by taking cleartype rendered text and magnifying it (thereby making subpixel rendering pointless), he's making low-DPI look artificially worse. He also makes the baffling suggestion to use 2x scaling for 4k. That means that your 4K monitor has the same amount of screen real estate as a 1080p monitor, a reduction in surface area of 43% compared to a sane low-dpi monitor @ 1440p. While I agree that it would likely result in better looking scaling, I can't imagine how slightly better looking text/scaling can make up for the loss in surface area. Personally I've regularly used 4k 27" and 1440p 27" monitors, and while the 4K monitor is clearer, it's not something that I'd fork over a few hundred dollars for.
历次讨论
同类还值得读
直接在浏览器中启动 Linux 内核
Boot a linux kernel right inside your browser.
Fabrice Bellard 的 JSLinux 页面，用 JavaScript 在浏览器里启动一个 Linux 内核，并提供一个可交互的终端环境。
工具与资源上首页 5 次 · 2011–2025bellard.orgHacker News 未公开功能与行为清单（2018）
A List of Hacker News's Undocumented Features and Behaviors (2018)
数据科学家 Max Woolf 整理的 Hacker News 未公开功能与行为清单，涵盖投票机制、排名算法、账号惩罚等社区运作细节。
工具与资源上首页 5 次 · 2019–2025github.comMapSCII：在终端中用盲文和 ASCII 渲染地图
MapSCII – Braille and ASCII map renderer for the console
MapSCII 是一个在命令行终端里渲染地图的开源工具，用盲文字符和 ASCII 字符把地理数据画成可交互浏览的字符地图。
工具与资源上首页 5 次 · 2017–2025github.com顶尖大学的免费在线课程
Free Online Courses from Top Universities
Open Culture 整理的一份免费在线课程合集，汇集了全球顶尖大学（如 MIT、斯坦福、耶鲁等）向公众开放的网络课程资源，涵盖音频、视频等多种形式。
工具与资源上首页 5 次 · 2010–2022openculture.com淘气字符串：容易引发用户输入问题的字符串清单
Naughty Strings: A list of strings likely to cause issues as user-input data
一个 GitHub 仓库，收录了大量容易让程序出问题的用户输入字符串，如特殊字符、emoji、SQL 注入片段、系统命令等，供开发者用于测试输入处理逻辑。
工具与资源上首页 4 次 · 2015–2020github.com