消费电子产品由硅驱动，却也遵循碳基世界里的自然法则：物竞天择，适者生存。

鼠标已年过花甲，形态上却几乎没有太大的变化。计算机 70 年历史，从一间房蜕变成家用电器甚至演化成每个人的囊中之物。

而像 BP 机、GPS 导航仪、iPod 更多的产品，还没来得及演化，就被其他产品吞噬而终成为一代人的记忆。

爱范儿《明日后视镜》栏目，我们将持续审视那些持续演化中的明日产品：它们从何种想法中孕育？又如何在变化中存续？它们如何塑造新生活方式，又如何被用户所改变？

生活中总有一类人，无法接受任何他觉得「现阶段不成熟」的电子产品。

我的朋友 K 就是其中的佼佼者——从 EarPods 到 AirPods，他等了两年半；从 Home 键到「上滑解锁」，他等了四年。

而最近，他看上了我手里这台 OPPO Find N6。

作为消费电子科技产品弄潮儿——也就是我——的朋友，K 并非没有接触过折叠屏。

比如在前几年我折腾二手 Z Flip 的时候，他就做出过这样的评价：

我本来以为它能展开一整块屏幕，但这个折痕总让我觉得它是「拼好屏」。

而在 K 摸过 Find N6 之后，我可以明显看到这个坚定保守派的动摇——相比曾经的 Z Flip，Find N6 的屏幕是字面意义上「不是一个时代」的产物了。

折叠屏的期待偏差

今年的 OPPO Find N6，最主要、也是最拿得出手的特点，就是这块号称「无感折痕」的内屏了。

然而就像 K 评论 Z Flip 的那样，「折叠屏」与「折痕」之间的关系，实际上存在另一套隐形的逻辑：

表面上看，人们都是因为折痕破坏了眼睛的视觉体验和手指的触觉体验，在使用过程中「打破沉浸感」而无法接受折痕存在的。

但回归问题本质，折叠屏的存在，其实是为了满足我们当初对于「人类迟早能从口袋里掏出一个 72 寸电视」的狂野幻想而生的——

折叠屏手机的重点，从来不是能折叠，而是能在口袋里塞下一块大屏！

换言之，曾经那些对「折痕」的口诛笔伐，往往都将关注点错误地局限在了「折痕破坏了折叠屏体验」的层次。

折痕真正破坏的，是我们潜意识中对于一块完整屏幕的认知：

更糟糕的是，过去几年间，手机厂商营销折叠屏的方式，也对这种错误认知起到了推波助澜的作用。

现在去看折叠屏机型的发布会，厂商往往无所不用其极地宣传「悬浮窗」、「工作台」、「多窗口」等等功能，完全不提操作这些「小票尺寸」的窗口有多不方便。

▲ 图｜CNET

而回头看 2019、2020 年折叠屏刚刚在市场上崭露头角时大家的期盼，就会轻易发现：

现在我们满脑子都是如何把一块 8 寸屏拆成两个甚至三个屏幕来用，却完全忘记了当年我们期盼的都是一整块 8 寸的大屏。

「折痕」所破坏的，正是这一层体验；Find N6 让我那个保守派朋友动摇的原因，正是给足了完整大屏的暗示。

Find N6 做对了什么

关于 OPPO Find N6 使用了哪些措施让原本显眼的折痕变得无感，我们在产品评测中已经进行了简单的介绍。

伴随着使用时间的加长、产品正式开售以及越来越多技术细节浮出水面，我们终于可以系统性地了解一下 OPPO 选择的技术路线了。

简单来说：Find N6 能够让折痕变浅乃至自修复，并不是因为什么外星科技，而是把现有柔性屏幕支撑技术发挥到了极致。

比方说 Find N6 的铰链，虽然本身只是控制机身开合的机械结构，但对于屏幕平整度同样有着至关重要的作用。

以往的折叠屏手机中轴铰链，需要借助数量不等的齿轮扭力结构将两侧衔接在一起，负责为机身开合以及悬停姿态提供足够的摩擦力和稳定性。

而出于体积、厚度和结构设计因素，以前的机型大多只会设置三组扭力结构，比如去年的 Find N5 就使用了这种「三轴」铰链：

▲ 图｜哔哩哔哩 @胜利文绉绉

这样的设计虽然省空间，但三组扭力结构之间的不等距，导致铰链对屏幕的支撑也不均匀，容易出现折痕「从上到下有深有浅」的问题。

到了 Find N6 这，OPPO 选择了一种既简单又困难的方式解决——既然三轴铰链支撑不均匀，那就换成四轴铰链。

这样一来，虽然 Find N6 的机身结构设计变得更复杂了，但铰链对于屏幕的支撑效果也均匀了许多，让工程师可以把精力放在折痕深度上：

▲ 图｜哔哩哔哩 @微机分WekiHome

解决了支撑的均匀度之后，就要解决如何支撑平整的问题了。

尽管厂商会将铰链顶层做平，尽可能让所有零件在摊开后形成一个平面，但生产和组装时候的细微公差仍然会导致零件高低差，给屏幕以下陷的机会。

为了解决这个问题，OPPO 选择了一个所有模型玩家都会做的事：喷一层补土。

更准确地说，是用流量控制精度极高的立体喷墨打印技术，搭配 3D 扫描，用填料喷涂在铰链的凹陷处，再进行光固化，让屏幕拥有更多的支撑点。

▲ 图｜OPPO

这个技术还是「因机而异」的。OPPO 甚至单独建了一条生产线，对每一台出厂的 Find N6 铰链进行单独的「找平」：

▲ 图｜哔哩哔哩 @微机分WekiHome

另一方面，Find N6 的屏幕本身也起着非常重要的作用。

毕竟折痕的形成，不仅仅是铰链的支撑力不够，「屏幕自己下陷」也是不可或缺的一环——

尽管表层屏幕可以使用柔性材料，但屏幕下方的支撑板却不能直接承受如此大角度和高强度的弯折。无论是不锈钢箔、碳纤维还是钛合金，都需要在折叠处蚀刻网状结构以释放应力：

▲ 三星超薄玻璃供应商 eCONY 开发的玻璃材质支撑板

但支撑板的镂空网刚好处在折叠屏折痕的位置，也就导致了矛盾：网状结构必须足够软才能弯折，但太软了又会被屏幕压弯，导致折痕变深。

为了解决这个问题，Find N6 选择在支撑网的工艺和屏幕材料两方面下手。

一方面，Find N6 的支撑网虽然还是传统的金属材质，但用上了三星同款的蚀刻工艺，将支撑网的开缝宽度从 0.1mm 缩小到了约 0.03mm：

▲ 图｜哔哩哔哩 @微机分WekiHome

开缝更小，支撑网的强度就更高，在屏幕展开的时候可以给上层的柔性材料提供更强的支撑，让折痕变得不那么「凹」。

同时，Find N6 还提升了屏幕表层 UTG 玻璃的厚度，以及屏幕每一层之间光学胶（OCA）的成分。

更厚的 UTG 玻璃除了提高屏幕强度之外，也让屏幕更不容易下陷形成折痕；改良过的光学胶则可以减小 OLED 屏幕各层之间的蠕变，以及在展平后有回弹的余量，让折痕慢慢「自我修复」。

这样一来，依靠铰链和屏幕「一下一上」的配合，Find N6 的确实现了那个曾经看来遥不可及的梦想：一台感觉不到折痕的折叠屏。

折叠不是答案，大屏才是

说来也巧，除了这台 Find N6 之外，我们手头刚好还有一台来自 2019 年的折叠屏手机。

并且不是随便哪台折叠屏，而是那台「开启了大折叠市场」的折叠屏——三星 Galaxy Fold：

七年过去，这台 Galaxy Fold 的成色当然不甚理想。原本松垮的铰链变得更加放荡不羁，就连屏幕本身都出现了细微的裂纹，已经失去了曾经的光鲜。

然而即使跨过这么多年，拿起这台 Galaxy Fold 最具有冲击力的第一观感，仍然是中间那条巨大的折痕：

无论是当年还是今天看这台 Galaxy Fold，我们都能感觉到它身上那股非常明显的「技术尚未成熟，同志仍需努力」的感觉。

但是 Galaxy Fold 的不成熟阻碍了「折叠屏手机」市场的发展吗？显然没有。

根据统计机构 Counterpoint 的数据，2025 年是全球折叠屏市场数据最强劲的一年，仅第三季度就实现了 14% 的同比增长，创下了折叠屏品类历史出货量的新纪录。

同时，国际数据公司（IDC）在《全球季度手机追踪报告》中预测，2025 年全球折叠手机出货量将实现超过 10% 的同比增长，全年全球出货量可能达到约 2100 万部。

▲ 折叠屏 vs 直板机年增长率对比｜IDC

如此强势的数据，其中大部分都是价格近万元的「大折叠屏」，对比波动不断的直板机市场，只能得出一个结论：

虽然折痕从 2019 年存在至今，但很明显并没有阻挡人们购买折叠屏手机。

毕竟从产品的角度看，2019 年发布的三星 Galaxy Fold 可谓「灾难性开局」，设计缺陷和品控问题轮番上阵，也没让市场对折叠屏产品失去信心，反而衍生出了其他形态更极致的产品——

帮助折叠屏市场在极不稳定的大环境里保持连年增长的，无外乎我们对于一块「更大的屏幕」的需求始终没有变过。

OPPO 通过 Find N6 实现的，表面上看只是让折叠屏的「折痕」变得可以接受，更深层次来说，更像是第一次让「一块大屏」的体验变得圆满了起来。

折叠屏不一定是智能手机形态的终极答案，但更大的屏幕——无论实体的还是虚拟的，一定是绝大多数用户的长期追求。

#欢迎关注爱范儿官方微信公众号：爱范儿（微信号：ifanr），更多精彩内容第一时间为您奉上。

「平坦」一直是我们对于屏幕的追求。

这种从 CRT 延续到 LCD、再到 OLED 的追求，在折叠屏的时代的重要性，更是有过之而无不及。

只不过碍于折叠屏的形态，「平坦」和「弯折」这两个词在过去就像水火不容一样，始终无法在手机上找到平衡点。

——直到我们遇见了手里这台 OPPO Find N6。

「无感折痕」为谁而来

在爱范儿拿到这台 Find N6 评测样机、几位编辑轮流当主力机使用过后，竟然罕见地达成了共识：

「无感折痕」的真正受众，不是折叠屏用户，而是没用过折叠屏、仍在犹豫的观望用户们。

道理也很简单，人们对于折痕的观感，会因为视角不同产生天差地别的变化——

比如从正常使用手机的角度观看亮屏的折叠屏时，只要没有强烈的条状光源或者反射，用户自己是完全看不到折痕的：

但如果以路人的视角，斜着看过去，原本不深的折痕也会因为光线折射的缘故，产生比实际深好几倍的视觉效果：

▲ 某友商折叠屏

此时再看相同角度的 Find N6，浅到几乎不可见的折痕，一下就拉开了和上面对照组的差距：

根据 OPPO 的介绍，Find N6 之所以能够做到「莱茵 TÜV 认证」的无感折痕，主要是通过优化铰链支撑结构，以及改良屏幕玻璃基材实现的。

其中，对于起到支撑作用的铰链中板，OPPO 通过重复 3D 扫描 + 超高精度喷射打印 + 紫外固化的流程，尽可能消除了铰链中板上的微观凹凸结构：

至于 Find N6 的「新款天穹记忆玻璃」——虽然名字很唬人，但本质是借助新的超薄玻璃（UTG）基材和叠层技术，减小了屏幕复合层在折叠时发生的拉扯和蠕变。

更加耐人寻味的是，Find N6 的新屏幕材料还可以让内屏和记忆金属一样，展开静置的时候缓缓「回弹」，淡化已有的折痕。

换言之，Find N6 的折痕之所以「无感」，还真不是展开或者合拢某个瞬间的事情，而是由使用期间每时每刻的细微变化构成的。

至少对于爱范儿编辑部几位用折叠屏做主力机的编辑来说，Find N6 的折痕表现难得地获得了一致好评。

而有了这样一块字面意义上「一马平川」的屏幕之后，Find N6 也带回了一个我们曾经非常熟悉的配件——手写笔。

具体来说，Find N6 借助更平整的屏幕，重新打通了手写笔 + ColorOS 全景自由窗的组合，让折叠屏分屏和小窗的好用程度更上一层楼。

毕竟折叠屏手写笔最大的敌人，就是划过折痕时带来的不安感。

而当折痕同时在「视觉」和「触觉」上消失之后，用笔尖在上面书写的芥蒂也就随之消失了：

此外，Find N6 的手写笔也扮演着和 ColorOS AI 功能交互的统一入口的角色。

通过「按住笔杆按钮圈选」的动作，就可以在几乎任何种类的内容上呼出 AI 功能窗口——圈住手绘的表格、脑图和文字，就可以一键转换成电子版图表：

▲ 录屏经过加速处理

甚至你还可以用它来画画。比起文生图模型需要你绞尽脑汁地描述画面，甚至上传参考图；在 Find N6 上你可以直接用笔画个线稿，然后圈选并告诉 AI 生成指定风格的图片：

▲ 录屏经过加速处理

作为一个每日高强度网上冲浪的用户，已经可以想象到这个功能在生成表情包时候的恐怖效率了。

除了这些生成式功能之外，Find N6 的手写笔在日常记录方面也有一些让人「爱不释手」的功能。

比如在评测期间，我们使用最多的就是 AI 字迹美化，可以让开会时随手写下来的灵感和想法变成工整、清晰的正式记录。

这样无论是阅读还是 OCR 转文字，效率都是大增：

▲ zh-MS

可惜这个功能目前的效果还比较简朴，只能优化「水平排版的简体中文和英文」，不支持繁体或者竖排文本。

不过需要注意：这次的 OPPO AI 手写笔是一个需要单独购买的配件，折叠键盘也是。两者售价均为 549 元，首销优惠价为 499 元：

影像不弱，但 N3 难再

虽然我们对 Find N6 的整体评价偏向正面，但在影像这个旗舰机的兵家必争之地，它的表现依旧需要重点拎出来聊聊。

Find N6 背面基本延续了上一代简洁利落的 Deco 风格，最大的改动反而是布局——

在 Find N5 的评测里，我们曾吐槽「把闪光灯硬塞进镜头模组是个败笔」。Find N6 由于丹霞色彩还原镜头的加入，闪光灯又回到了背面角落，值得好评。

而我们也可以大胆猜测：这种闪光灯位于机身角落凸起的设计，估计会成为接下来 OPPO Find X9 Ultra 和 X10 系列的标准。

有了丹霞色彩还原镜头的加入，Find N6 的后置镜头也来到了熟悉的四摄阵容，分别是：

• 5000 万像素超广角镜头
• 两亿像素主摄
• 5000 万像素潜望长焦镜头
• 丹霞色彩还原摄像头

纸面配置看起来不错，落到实际出片表现如何呢？

对主摄来说，虽然比不上一英寸大底的扎实感，但有两亿像素兜底，哪怕是裁切到 28 或 35mm 这种经典人文焦段，画面解析力依然经得起放大细看：

Fine N6 的长焦原生焦段是 3 倍，光圈来到了 f2.7，并且在近距离拍摄时可以提供一定的微距能力，背景虚化过渡也还不错。

此外，OPPO 还在这颗 3 倍长焦的基础上给出了一个类光学变焦的 6 倍选项，与超广角、1 倍、3 倍组成四个预设焦段。

等效 139mm 的焦段可以提供强烈的画面空间压缩感。实测素质相比 iPhone 17 Pro 上的 8 倍变焦稍弱，但作为一台折叠屏的拓展焦段，基本可以满足日常使用。

不过用折叠屏拍照，不只是硬件素质决定的，体验也是不可忽视的一环——不知道有多少人跟我有同感，非常排斥展开内屏拍照。

按理说，用大屏幕取景应该很震撼。但现实恰恰相反，取景框预览的画质会随着尺寸陡然变大而剧烈劣化：

▲ 使用相同倍率放大

这不仅是 OPPO 面临的问题，更是整个折叠屏行业的通病——要在这么大的屏幕上跑满预处理算法，手机的功耗和发热根本压不住。

理智上，我完全理解这种算力与功耗的平衡术。

但在实际体验中，展开一台万元折叠屏，取景框观感却只有个 720P，的确很影响拍照时的「心流」。

在功能生态上，Find N6 几乎照搬了当家的 X9 系列的全部家当。其中最直观的感知，在于丹霞色彩还原镜头这个硬件的加入。

面对霓虹闪烁或明暗交错的复杂光线，Find N6 的色彩表现比上一代 N5 稳了太多；配备哈苏自然色彩科学的大师模式也如约而至。

另一个细节是，根据我们实测来看，Find N6 的 XPAN 模式似乎悄悄换了底层逻辑，默认调用的不再是常规算法，而换成了大师模式的内核，行为更接近传统相机的「全局测光」。

换句话说，Find N6 的 XPAN 模式相比前代，光影过渡显得更自然、更有质感了不少：

有趣的是，在 OPPO 折叠屏手机的报道中，评论区永远有人在怀念 N3。

这部三年前发布的手机将彼时接近旗舰的硬件塞到了手机背面，给不少读者留下了深刻印象，但很遗憾——

Find N3 推出的年代，折叠屏这个形态还在探索的路途中，各家厂商各有下注，颇有「乱拳打死老师傅」的试探感。

这也才有了 N3 作为折叠屏，竟然有双层晶体管像素技术的 LYT-T808 做主摄、超广角与长焦尺寸都处于第一梯队或领先的盛况。

而时至今日，跳出单款产品去看整个折叠机大盘，目前悬在厂商头顶的达摩克利斯之剑已经得到共识。

在越来越薄的机身里，折痕的优化、电池密度的突破以及系统交互的易用性这些关乎日常体验的痛点被彻底抹平之前，影像性能的优先级只能被迫让步。

等待地基彻底打牢，高楼才能平地而起。

当年 Find N3 试图在折叠形态下打造巅峰影像的疯狂，可能短期内很难重演。

折叠屏的入坑机

实话说，相比去年突破厚度极限的 Find N5，今年的 Find N6 实际上在尺寸三围与 N5 并无差异，背板从素皮换成玻纤带来的减重倒是实打实的。

但在相同的机身里，Find N6 塞下了一块 6000 毫安时的电池、全局峰值亮度 1600 尼特的内外双屏、IP58/59 防水，以及最重要的——

一块几乎可以算是「无可感折痕」的屏幕。

从各个角度来看，这都是那些之前对折叠屏持犹豫态度的人真正「入坑」的好时机：几乎和直板机相同表现的电池，有独特影调的相机，以及终于不再是阻碍的屏幕体验。

同时，ColorOS 在目前的主流折叠屏市场中也算是一股清流。

相比另外几个主打「雍容华贵」和「水土不服」的折叠屏系统，我们认为 ColorOS 是目前综合本地化功能、设计审美和 AI 实用程度之后，能够在折叠屏手机上获得的最佳体验。

当然，折叠屏的体验同样是靠价格换来的。在存储大涨价的时代背景下，OPPO Find N6 的价格算不上有惊喜——

起步版本 12+256GB 售价 9999 元，16+512GB 则来到了 10999 元，顶配的 16+1TB 卫星通讯版更是上探到了 11999 的价位段：

不过对于那些原本就有计划换机的人来说，这样一台功能不瘸腿、审美更青春、影像有兜底，且屏幕体验出奇好的 OPPO Find N6 ，称得上是 2026 年迄今「最适合观望用户入场」的一台折叠屏——

#欢迎关注爱范儿官方微信公众号：爱范儿（微信号：ifanr），更多精彩内容第一时间为您奉上。

If you have been trying to use my free utility Providable on a non-English system and have been unable to get it to list apps installed there, you will want to download and use this new version 1.2, which should address that problem.

It’s available from here: providable12
and will shortly be getting its own place in a Product Page, and in Downloads above.

Just to demonstrate that Providable 1.2 does list apps correctly in non-English systems, here’s a screenshot of version 1.1 in the upper left showing no apps found, and 1.2 in the lower right with the three apps it should have identified. That’s in Tahoe 26.2 with Chinese set as the primary language.

The rest of this article explains why previous versions failed to list installed apps on non-English systems, why that has more general significance, and how it’s bad behaviour.

Listing apps

It’s curiously difficult to obtain a comprehensive list of apps installed on a Mac. If you look at proposed solutions, many involve iterating through popular locations such as Applications folders, or other time-consuming schemes. This turns out to be duplicated effort, as Spotlight already does that when indexing, and provides indexes you can search far more quickly.

The common recommendation is to use the mdfind command in the form
mdfind "kMDItemKind == 'Application'"
which should find all items that Spotlight has indexed as being of the kind Application. There’s an equivalent available in the Finder’s Find window that demonstrates how well this can work.

As Apple doesn’t appear to explain any further about how Spotlight classifies items into these ‘kinds’, it’s reasonable to assume they are categories with standard names, although that proves to be incorrect when you try the same on a non-English system. You then realise that a ‘kind’ is just an arbitrary string that may be localised. Run that command in macOS localised to Chinese, and you won’t find any Application at all, and when localised to Italian you’ll need to use Applicazione instead.

The textbook solution to localisation problems like this is to provide a set of localised strings, and to pick the correct one depending on the current localisation setting. That may work when you have specialist teams, and can achieve comprehensive cover of all the possibilities, but here it’s impractical, as it would be when writing a script that uses that search command. It’s much better to cheat.

The most obvious way around this is to use a criterion that’s localisation-invariant such as a UTI. You can then search for .app bundles with the UTI of com.apple.application-bundle. I was disappointed to discover that too isn’t as simple as it could be, as UTIs are available in kMDItemContentType, but according to current documentation that returns a complete UTI ‘pedigree’, for an app something like com.apple.application-bundle/com.apple.application/com.apple.localizable-name-bundle/com.apple.package. That may not be correct, though, as using mdls to list metadata shows that the full pedigree is given in kMDItemContentTypeTree rather than kMDItemContentType.

Preparing for both cases, the correct search command should then be
mdfind "kMDItemContentType == 'com.apple.application-bundle*'"

And that is exactly what Providable 1.2 does now.

Does Spotlight reindex when changing localisation?

My next question is what Spotlight actually indexes for kMDItemKind: is the string localised or not? As we don’t have direct access to those indexes, the closest we can come to inspecting them is by dumping metadata using mdls. Using Italian and English as my examples, when running with English as the primary language, kMDItemKind for an app is given as Application, but with Italian primary, it’s given as Applicazione instead.

This is the only metadata that appears localisation-dependent in this way, so either mdls is lying by returning a localised string, or Spotlight is rebuilding its index for kMDItemKind when the primary language changes. Neither behaviour is documented or expected.

Localisation overreach

This isn’t the first time that I’ve run into problems with localisation in command tools. If you use SilentKnight on Apple silicon Macs running non-English systems, you’ll be only too aware of my previous and apparently insoluble issue, where a major command tool can only return strings in localised form, effectively making their interpretation impossible. In that case it’s one of the many modules in system_profiler, returning key information about an Apple silicon Mac’s security status that isn’t readily available anywhere else.

Localisation is wonderful, and vital for many of us using macOS, but in some cases is now being applied too early. I wonder how anyone scripting with mdfind can possibly make use of kMDItemKind across different localisations. If its kinds were drawn from a set of non-localised strings, there would be no such problems. It makes good sense to localise the strings used in its GUI equivalent, but not for the command tool.

There are many examples of where localisation doesn’t take place, for example in UTIs, and in filename extensions. Can you imagine the consequences of localising the latter?

I’m very grateful to Hill-98 for helping me uncover these problems.