macOS 26把圆角玩砸了：开发者用23行代码强行"统一"

升级macOS 26的用户里，有批人宁愿关掉系统安全防护，也要把窗口边角改回去。不是为了好看，是为了"眼不见为净"——同一台电脑上，Safari的圆角弧度、系统设置的圆角弧度、第三方应用的圆角弧度，三家各画各的，像三个设计师吵架后谁也没服谁。

圆角战争：从"谁更圆"到"能不能统一"

这事得从苹果的设计执念说起。macOS 26把窗口圆角推到了新高度，但执行层面出了岔子：系统级应用一个标准，第三方应用另一个标准，同一套UI里能同时出现3种不同的圆角半径。有用户在Reddit吐槽，"看久了像在看不同年代的OS拼贴"。

更麻烦的是，这种不一致不是bug，是架构层面的遗留。Safari这类系统应用用的是私有API（应用程序编程接口），第三方开发者拿不到同样的绘制参数，只能自己猜。猜多了就歪，猜少了就方，最后满屏幕都是"差不多圆"。

一位前端开发者形容这种体验："像穿了一套西装，但袖口、领口、裤脚的剪裁各出自不同裁缝。"

极端解法：关掉安全防护，硬改系统文件

社区里流传最广的"修复方案"，是关闭SIP（系统完整性保护）。这是macOS的安全基石，关掉后root分区（系统核心目录）不再受保护，用户可以修改系统级动态库，强行给Safari等应用"换皮"。

风险很明显：恶意软件一旦突破用户层，就能在系统核心区域扎根。但支持者辩称，"都拿到你机器权限了，SIP挡不挡root区别不大"。

这种争论本身就很荒诞——用户为了视觉统一，要在"难看"和"不安全"之间二选一。而苹果官方至今没有回应，仿佛这不在优先级列表里。

一位参与讨论的安全研究员 bluntly 指出：「让用户为了UI一致性去权衡安全，这产品设计本身就失败了。」

反向操作：与其改回去，不如全改圆

GitHub上有个叫"Make macOS consistently bad"的项目，作者没走"去圆角"的老路，而是反其道行之：把所有窗口的圆角半径统一调到23像素，比苹果现在的最圆版本还要圆。

代码很直白。通过Objective-C的运行时方法交换（Method Swizzling），劫持NSThemeFrame类的四个关键方法：_cornerRadius、_getCachedWindowCornerRadius、_topCornerSize、_bottomCornerSize。所有返回值硬编码为23.0，系统画圆角时拿到的永远是同一个数字。

作者特意加了道保险：只作用于第三方GUI应用，跳过命令行工具、后台守护进程和苹果官方应用。bundleIdentifier以"com.apple."开头的，一律放行。

这个方案的优势在于不动系统文件，不需要关SIP。劣势也很明显——它管不了Safari，因为Safari的bundle ID正是"com.apple.Safari"。

设计传染：为什么这事不止关乎苹果

项目作者在README里写了一段行业观察，值得细读：

「UI设计是我见过影响力最离谱的领域。设计师吵架时，输的一方最后总会说，'看看苹果怎么画的那个按钮'。大公司做什么，整个行业就跟着做什么。」

他举了YouTube的例子：当前YouTube的UI圆角"过度"到让他不适，但他赌五毛，这种风格很快会蔓延到其他地方。"因为苹果开了头，其他人就有了借口跟进。"

这种"设计霸权"的副作用是，当带头大哥自己执行歪了，跟风的只会歪得更离谱。macOS 26的圆角混乱，可能正在孵化下一轮"各圆各的"视觉灾难。

项目作者的解决方案本质上是一种抗议：既然你们统一不了，我帮你们统一，哪怕统一得更夸张。

目前这个fork在GitHub上收获了数百星标，评论区最常见的问题是："能不能把Safari也包进来？"答案是不能，除非苹果自己松口，或者用户愿意关掉那道安全闸门。

所以问题来了：你会为了视觉统一，接受一个"圆过头"的macOS，还是宁愿忍受现在的参差不齐，等苹果某天想起来修？