阅读视图

发现新文章,点击刷新页面。
🔲 ☆

Go 标准库竟然也用 vendor?std 和 cmd 模块是如何管理外部依赖的

本文永久链接 – https://tonybai.com/2026/01/28/go-standard-library-vendor-std-cmd-dependency-management

大家好,我是Tony Bai。

我们都知道,Go 推荐使用 Go Modules 来管理依赖。但在 Go 源码树的最深处,隐藏着一个鲜为人知的秘密:Go 标准库 (std) 和工具链 (cmd) 竟然依然在使用 vendor 目录来管理它们的外部依赖。

为什么官方要“反其道而行之”?当你在 crypto/tls 中引入 golang.org/x/crypto 时,底层到底发生了什么?今天,让我们潜入 $GOROOT/src,解密一下 std 和 cmd 这两个特殊模块的依赖管理之道。

标准库的双重身份:std 与 cmd

在 Go 的源码树中,其实存在着两个特殊的模块(module),它们定义了 Go 核心代码的依赖边界:

  1. std 模块 (src/go.mod):这是我们熟知的标准库。它不仅包含 net/http、os 等核心包,还显式依赖了 golang.org/x/crypto 和 golang.org/x/net。

看看 当前 Go 主干 (Go 1.27开发分支)中的 src/go.mod:

module std

go 1.27

require (
    golang.org/x/crypto v0.47.1-0.20260113154411-7d0074ccc6f1
    golang.org/x/net v0.49.1-0.20260122225915-f2078620ee33
)

require (
    golang.org/x/sys v0.40.1-0.20260116220947-d25a7aaff8c2 // indirect
    golang.org/x/text v0.33.1-0.20260122225119-3264de9174be // indirect
)
  1. cmd 模块 (src/cmd/go.mod):这是 Go 的工具链。它包含了 go 命令、gofmt、pprof 等工具,其依赖更加广泛,涵盖了 x/tools、x/mod 、github.com/google/pprof,甚至是Russ Cox和Ian Taylor两位Go核心大佬的私人Go module。

当前最新cmd/go.mod内容如下:

module cmd

go 1.27

require (
    github.com/google/pprof v0.0.0-20260115054156-294ebfa9ad83
    golang.org/x/arch v0.23.1-0.20260109160903-657d90bd6695
    golang.org/x/build v0.0.0-20260122183339-3ba88df37c64
    golang.org/x/mod v0.32.0
    golang.org/x/sync v0.19.0
    golang.org/x/sys v0.40.1-0.20260116220947-d25a7aaff8c2
    golang.org/x/telemetry v0.0.0-20260116145544-c6413dc483f5
    golang.org/x/term v0.39.0
    golang.org/x/tools v0.41.1-0.20260122210857-a60613f0795e
)

require (
    github.com/ianlancetaylor/demangle v0.0.0-20250417193237-f615e6bd150b // indirect
    golang.org/x/text v0.33.1-0.20260122225119-3264de9174be // indirect
    rsc.io/markdown v0.0.0-20240306144322-0bf8f97ee8ef // indirect
)

这意味着,虽然标准库被认为是“零依赖”的基石,但实际上它在内部复用了大量 golang.org/x 下的高质量代码。

vendor 的魔法:重命名与隔离

既然用了 Module,为什么 std 和 cmd 还要维护 src/vendor 和 src/cmd/vendor 目录?

这就涉及到了 Go 编译器的底层机制。当标准库内部的代码引入外部包时,发生了一个神奇的重命名 (Renaming) 过程。

当 crypto/tls (在 std 模块中) 导入 golang.org/x/crypto/cryptobyte 时,编译器并不会去 Module 缓存里找,而是将其解析为:
vendor/golang.org/x/crypto/cryptobyte

这样做有两个关键目的:

  1. 绝对隔离:这保证了标准库使用的 x/crypto 版本与用户项目中使用的版本是完全物理隔离的。你的项目可以依赖 v0.1.0,而标准库可以依赖 v0.47.1,两者在最终二进制中是两个路径完全不同的包,互不干扰,绝无版本冲突之虞。
  2. 路径规范:标准库有一个潜规则——包路径元素中不能包含点号(除了域名)。加上 vendor/ 前缀巧妙地将 golang.org 这种带点号的路径“内化”为了标准库的一部分。

如何维护这套系统?

维护这套庞大的依赖系统并非易事。Go 团队在 src/README.vendor 中记录了一套严格的工程流程:

  1. 环境准备:必须在 GO111MODULE=on 且 GOWORK=off 的纯净环境下操作。
  2. 更新流程
    bash
    cd src # 或者 cd src/cmd
    go get golang.org/x/net@master # 更新依赖
    go mod tidy # 清理 go.mod
    go mod vendor # 更新 vendor 目录
    go test cmd/internal/moddeps # 运行一致性检查
  3. 发布周期:在每个 Go 主版本开发周期中,std 和 cmd 的依赖至少会被全面更新两次,以确保标准库不会滞后于社区的最佳实践。

小结

Go 官方对 std 和 cmd 的管理方式,其实是一种“单体仓库 (Monorepo) + 依赖固化”的最佳实践。

  • 稳定性优先:通过 vendor,Go 确保了标准库构建的绝对可复现性,即使在无网络环境下也能完美构建。
  • 依赖隔离:通过路径重写,优雅地解决了“依赖地狱”中的版本冲突问题。

下次当你感叹 Go 标准库的稳定与强大时,别忘了这背后,有一套精密设计的 Vendor 机制在默默支撑着这一切。

参考资料:https://github.com/golang/go/blob/master/src/README.vendor


你的“Vendor”情结

虽然 Go Modules 已经统治了世界,但 vendor 依然在标准库和许多企业级项目中发光发热。在你的项目中,你还在使用 vendor 目录吗?是
为了离线构建,还是为了像标准库一样实现“依赖固化”?

欢迎在评论区分享你的依赖管理策略!让我们一起探讨 Go 工程化的最佳实践。

如果这篇文章揭开了你心中关于标准库的谜团,别忘了点个【赞】和【在看】,并转发给身边那些爱钻研源码的朋友!


还在为“复制粘贴喂AI”而烦恼?我的新专栏 AI原生开发工作流实战 将带你:

  • 告别低效,重塑开发范式
  • 驾驭AI Agent(Claude Code),实现工作流自动化
  • 从“AI使用者”进化为规范驱动开发的“工作流指挥家”

扫描下方二维码,开启你的AI原生开发之旅。


你的Go技能,是否也卡在了“熟练”到“精通”的瓶颈期?

  • 想写出更地道、更健壮的Go代码,却总在细节上踩坑?
  • 渴望提升软件设计能力,驾驭复杂Go项目却缺乏章法?
  • 想打造生产级的Go服务,却在工程化实践中屡屡受挫?

继《Go语言第一课》后,我的《Go语言进阶课》终于在极客时间与大家见面了!

我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造!30+讲硬核内容,带你夯实语法认知,提升设计思维,锻造工程实践能力,更有实战项目串讲。

目标只有一个:助你完成从“Go熟练工”到“Go专家”的蜕变! 现在就加入,让你的Go技能再上一个新台阶!


商务合作方式:撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求,请扫描下方公众号二维码,与我私信联系。

© 2026, bigwhite. 版权所有.

🔲 ☆

草梅 Auth 1.12.0 发布与墨梅博客立项经验 | 2025 年第 50 周草梅周报

本文在 草梅友仁的博客 发布和更新,并在多个平台同步发布。如有更新,以博客上的版本为准。您也可以通过文末的 原文链接 查看最新版本。

前言

欢迎来到草梅周报!这是一个由草梅友仁基于 AI 整理的周报,旨在为您提供最新的博客更新、GitHub 动态、个人动态和其他周刊文章推荐等内容。


本周依旧在开发 草梅 Auth 中。

你也可以直接访问官网地址:https://auth.cmyr.dev/
Demo 站:https://auth-demo.cmyr.dev/
文档地址:https://auth-docs.cmyr.dev/

本周 草梅 Auth 发布了 1.12.0 版本。

image-20251214193150948

本周还是继续进行重构工作,对项目代码的结构进行了重大调整,在 diff 中也可以看到该版本进行了多少改动(涉及近 200 个文件)。

不过,必须要指出的是,现在的重构工作之所以这么麻烦,很大程度上还是前期开发中遗留了太多的坑,以至于现在要填上就得费九牛二虎之力才行。

如果从一开始就重视代码质量,注意测试覆盖率,那么现在重构起来也不会这么痛苦。

所以,我在开发草梅 Auth 中得到的一个很重要的教训就是,有些事必须从一开始就开始做,否则后面再补上会非常麻烦。

如果想了解如何部署和使用项目,可以参考文档的内容,也欢迎补充文档缺失的内容。

如果你对草梅 Auth 感兴趣,欢迎参与开发和测试。


本周开启了一个全新的项目——墨梅 (Momei),也叫墨梅博客。

image-20251214193407257

当前 UI 仅为示意图,还未定稿

开启这个新项目的原因也很简单,那就是我想有个新的博客了。

我当前博客(草梅友仁的博客)是基于 Hexo 的静态博客,使用的是 Next 主题。

作为静态博客,Hexo 自然有它的好处,那就是后端无关,部署起来成本低,基本上就只有流量费用,而静态网站的托管也很容易。

不过,Next 主题年久失修(已经有 4 年没关系了),加上 Hexo 作为静态博客,也存在天然的局限性,使之不太能像动态博客那样提供用户订阅、访问统计等功能。

虽然说能通过插件实现,不过 Hexo 官方是未提供相关功能的

此外还有国际化难度大的问题。

种种原因,使得我想更换一个博客平台。

在去年的时候,曾经研究过 WordPress ,虽然说 WordPress 确实功能强大,但是 WordPress 对服务器资源占用非常高,同时页面访问也慢,种种原因之下,还是选择了放弃使用 WordPress。

WordPress 是一个基于 PHP 的动态博客平台,功能非常强大,也很火。

因此,既然没有找到合适的博客平台,那不如自己写一个吧!

至少写了之后自己也能用下。

当产生了自己写一个博客的想法之后,接下来就是实现了。

在 AI 工具火热的今天,有什么想法的话,第一步就是问问 AI。

我这里也是直接问了下豆包,“一个合格的博客项目需要有哪些功能,还可以有哪些创新点?”

image-20251214194902503

你也可以用任何你喜欢的带搜索引擎功能的 AI,注意,一定要带搜索引擎,以确保信息是最新的,否则 AI 可能会返回过时的信息

豆包的回复其实还挺详细的,不过我自己还有别的想法,就让它再加点功能。

image-20251214195009367

反复几轮之后,再让它总结聊天记录,作为最初的设计需求。

image-20251214195027051

之后就是设计原型图了。

image-20251214195103392

但老实说豆包生成的图片原型并不好看,我最终也没有采用,是直接叫它生成静态 HTML 的版本,还更好一些。

image-20251214195229931

不过因为我并不喜欢使用 Tailwind CSS,还是叫它去掉了

此外也顺便生成了一下项目名称和 Logo。

image-20251214195305400

给项目取名称的过程其实还挺值得说道的,这里涉及到几个小技巧。

取项目名称有两种方案,一种是直接蹭已有的热门名称,借助原主的热度来给自己的项目增加热度,不过风险就是很容易被别人盖过去,从而得不偿失。

另一个就是找个相对冷门的名字,以确保自己可以独占名称,不过这样一来推广的难度也会上升,毕竟冷门名称之所以冷门也是有原因的。

在具体的方法上,可以结合搜索引擎关键词和域名可用性来决定。

在搜索引擎关键词上,你可以借助 Ahrefs 来查看关键词进入前 10 名搜索结果的难度。

建议优先选择竞争压力小的关键词。

image-20251214195811216

不过 ahrefs 上没有中国大陆地区的数据,如果要看中文区的数据,可以参考香港和台湾地区的数据。

域名可用性则更简单一点,找个域名注册平台看一下就行。

举个例子,一开始我想用“墨渡”这个名称,在中文搜索词中竞争压力不大,结果 modu 这个域名已经被人注册完了,我也只能选择换个名称。

image-20251214200618057

.com 根域名的竞争难度还会更大,此时可以看一下别的,比如 .app.dev 等,对独立开发者来说也非常好用

此时还要格外注意的是,一定要看下项目名称是否存在同名的竞品。

如果只是同名的话问题不大,但如果刚好是同类竞品,那还是建议放弃。

rss-zero 这个项目之所以归档了,还是因为刚好存在同类竞品,名称完全一样,对方还持有 .com 域名,在这种情况下,我基本上只有换个名字或者直接放弃的选择了。

这个失误在于忘了搜 rss0 这个关键词,只搜了 rss-zero 。所以如果你的项目名称存在多个变体,建议都搜一下。

在敲定了名称之后,也就可以设计对应的 logo,到这里,一个项目的原型也差不多可以出来了,后续就是一些软件开发上的问题了,而这些,就是 AI 的强项了。

应该说,在 AI 工具越来越强大的今天,想要开发一个新的软件变得越来越容易,笔者也采用了先和 AI 沟通好设计方案,先写完文档,再进行 AI 编程的方法,来写代码。

在这个过程中,正确的 AI 开发方法论变的非常重要。

再次还是继续推荐看一下 《方糖 AI 自编程入门》,想必会对你有所收获。

总之,最重要的一点就是添加测试用例,如果不知道怎么写,就让 AI 帮忙完善。

当测试覆盖率达到 60% 以上的时候,代码质量一般不会太低,而且如果后续迭代中改出问题了,也容易发现。

以上就是笔者在这次 墨梅博客 的立项过程中的一些经验和教训,希望对你有所帮助。

最新 GitHub 仓库

  • momei - 2025-12-11 01:43:55
    墨梅 - 轻量跨语言博客创作平台。支持旧博客无缝迁移、多语言内容管理、简洁 Markdown 创作,基于 Nuxt3/Vue/TS 构建,为创作者提供无冗余的高效内容工具。

GitHub Release

caomei-auth

v1.12.0 - 2025-12-13 20:13:52

摘要:
版本 1.12.0 摘要 (2025-12-13)

新功能:

  • 新增公共路径、二维码生成和智能输入处理实用功能
  • 封装基础对话框组件统一布局和响应式设计
  • 添加多个 Composables 优化代码结构和交互体验
  • 新增用户注册、密码修改和管理相关表单 Schema
  • 引入 form-group 组件优化表单布局
  • 添加 status-badge 组件统一状态管理
  • 新增 useApi 和 useForm 组合式 API

Bug 修复:

  • 修复 useForm 响应式数据访问问题
  • 修正搜索输入空值处理逻辑
  • 改进日期格式化函数空值处理
  • 修复第三方账号展示问题
  • 统一状态属性命名规范

代码重构:

  • 优化登录、密码找回等页面结构
  • 改进日志管理和通知模板功能
  • 使用 Zod Schema 增强表单验证
  • 重构数据表组件和社交账户逻辑
  • 统一对话框和表单组件实现
  • 简化函数参数和组件结构
  • 优化代码导入路径和类型定义

cmyr-template-cli

v1.42.2 - 2025-12-11 02:11:21

摘要:

GitHub Release 摘要 (v1.42.2)

Bug 修复

  • 移除了 vitest 测试框架配置中的覆盖率设置项

v1.42.1 - 2025-12-11 01:50:03

摘要:
[1.42.1]版本更新摘要:

Bug 修复:

  • 更新了模板元数据配置
  • 启用了 Docker 支持功能
  • 注释掉了 webpack 模板配置

本次更新主要针对模板配置进行了调整,重点增加了 Docker 支持并移除了 webpack 相关配置。

最新 GitHub 加星仓库

  • CaoMeiYouRen starred feedsmith - 2025-12-12 13:43:50
    一款全功能的 JavaScript feed 解析器和生成器,支持 RSS、Atom、RDF 和 JSON Feed 格式,兼容主流命名空间和 OPML。采用 TypeScript 作为主要开发语言,在 GitHub 上获得 529 星标。
  • CaoMeiYouRen starred cloudflare-error-page - 2025-12-11 19:34:36
    Cloudflare 错误页面生成器,主要使用 EJS 模板语言开发,在 GitHub 上获得 2859 个星标。
  • CaoMeiYouRen starred index-tts - 2025-12-09 23:47:58
    该 Python 项目是一个工业级可控高效的零样本文本转语音系统,获得了 16596 个星标。系统具备零样本学习能力,可直接转换未见过的文本为语音,同时保持工业应用所需的高效性和可控性。项目在 GitHub 平台上受到广泛关注,表明其在文本转语音领域的技术先进性和实用价值。
  • CaoMeiYouRen starred RedInk - 2025-12-09 15:10:56
    红墨是基于 Nano Banana Pro 开发的小红书图文生成工具,支持通过一句话自动生成图文内容。该项目使用 Python 语言开发,在 GitHub 上获得了 3629 个星标。

其他博客或周刊推荐

阮一峰的网络日志

HelloGitHub 热点速览

潮流周刊

二丫讲梵的学习周刊

总结

本周的更新和动态如上所示。感谢您的阅读!
您可以通过以下方式订阅草梅周报的更新:

往期回顾

本文作者:草梅友仁
本文地址: https://blog.cmyr.ltd/archives/2025-50-caomei-weekly-caomei-auth-1-12-0-momei-blog.html
版权声明:本文采用 CC BY-NC-SA 4.0 协议 进行分发,转载请注明出处!

🔲 ☆

浅谈苹果的命名困局:从Pro、Air说开去

西方语境中,13 不是一个好数字,背叛耶稣基督的犹大,据信是最后的晚餐餐桌上第 13 个就座的人。于是,西方人不喜欢数字 13 的传统一直延续到今天,很少有人宴客会邀请 13 个人,12 或 14 人都可以,13 不行。

不巧的是,9 月即将发布的新 iPhone,按照产品迭代,正好是 iPhone 13。苹果会考虑另一个名字来代替它吗?就像 iPhone X 那样?

具体选用哪个字母或数字,还要等到发布会才会揭晓。不过,回顾苹果产品线的命名史,其实可以窥见苹果虽然以简洁的市场文风著称,但有时仍会陷入不可解的命名困局。本文以 Mac、iPhone、iPad 三大产品线的命名演变史,来尝试还原苹果在开辟产品线及市场定位上的诸多困局与转变。

Mac:经典四象限命名,演变至今

之所以要先提 Mac(泛指苹果电脑产品线,下文同),是因为其 Pro 和 Air 命名影响了太多后来者。

后来者对苹果产品外观的模仿很容易让人理解,但为何连命名都要直接借鉴?原因无非两点,一是苹果自身的品牌跟进效应,二是这样的命名确实可以让消费者快速知晓产品线的特点与不同。

很明显, 无论是西文还是中文语境,Pro 让人联想到 Professional,主打专业与性能;Air 则让人联想到空气,主打轻薄便携。

这样精准、简洁的命名来源于乔布斯。

很长时间里,苹果都是作为一家电脑公司出现在人们视野,电脑产品线上根据「Apple」「Macintosh」延伸出多种多样的型号。

比如:

苹果之前种类繁多的产品线

1990 年,乔布斯重回苹果,他将苹果的产品线缩减为简单的四象限,横轴两边分别为「消费者」「专业」,竖轴两边分别为「便携」「桌面」。消费类产品带有前缀「i」,而「Power」则保留给专业级产品使用。

乔布斯当时的四象限命名法

这样的结果是:乔布斯的四象限命名法帮助苹果精简了产品命名上的诸多历史问题。

Power阵营 VS i 阵营

四象限的精妙之处在于,它可以明确每种产品的用途,让消费者一目了然。直到 2006 年,苹果都在沿用四象限命名法。

2006 年,苹果将电脑芯片从 Power 转向英特尔芯片阵营,这一年,除了 iMac 和 Mac mini 不变,其他所有的电脑名称都发生了变化。

面向消费者的 iBook 系列变成了 MacBook,面向专业消费者的 PowerBook 系列变成了 MacBook Pro,而面向专业消费者的 Power Mac 台式电脑系列变成了 Mac Pro。

消费者 VS专业消费者

乔布斯的四象限到此结束,Power 被 Pro 所取代,i 变成了 iOS 设备所专属(iPad、iPhone、iPod,除了 iMac),而在后面晚几年登场的 Watch、Pencil、TV,苹果重新沿用了 Apple 前缀,分别命名为 Apple Watch、Apple Pencil、Apple TV。(有意思的是,TV 最早代号是 iTV)

MacBook家族演变史

可以看出,乔布斯的第一次命名调整帮助苹果梳理了内部产品线,使之更为简洁,而第二次命名调整则是和公司整体战略相关。

iPhone:较为混乱,稍有秩序

Mac 作为生产力领域设备,同时模块化较强,无论是 CPU 强劲程度,显卡配置、屏幕尺寸都需要明确市场定位,从而可以让各种需求的消费者,能够快速找到适合自己的设备,这也是 Pro、Air 至今仍沿用的根本原因。

但是 iPhone 作为最为大众的消费类电子产品,大部分人关注的可能并不是性能,那苹果要如何做好市场定位及品宣,尽可能多地占据市场份额呢?

多品类出货无疑是最好的选择,但这也同样给 iPhone 带来了命名混乱。

其实,客观来说,从 2007 年的一代 iPhone 到现在的 iPhone 12,苹果起初定型于以每两年做一次数字迭代的方法命名新产品。(如一年 iPhone 5,下一年 iPhone 5S)

两年大迭代的频率持续到 iPhone 6 为止,也是在这一年(2014),各大手机厂商开始了大屏时代,这一年,新型号 iPhone 6 Plus 登场。

iPhone 6、iPhone 6 Plus

Plus 除了表示更大的屏幕之外,还有别于原版一些功能特性。如iPhone 7 Plus 相比 iPhone 7 ,多了一颗摄像头。

2015 年是让苹果开心的一年,这一年,iPhone 总销量达到历史巅峰 2.312 亿台,销售额达到 1550 亿美元。

或许是觉得「S」在人们眼里是小版本的修修补补,如何让抱着「下个版本见」的用户也加入换机浪潮,是苹果需要考虑的一大问题。于是,接下来,「S」不见了。

2016 年 iPhone 7 发布,2017 年 iPhone 8 发布,再也没有中间态「S」了。但是苹果手机的销量并没有因此而提升,反而持续下滑,2020 年营收下滑到 1377 亿美元。

苹果每季度营收情况,2015年开启了年度巅峰

2017 年 11 月,苹果在已经发布过 iPhone 8 的前提下,又发布了新机 iPhone X,直接跳过了 9 的命名。

而到了 2018 年,新机命名好像又回到了微更新「S」时代。

  • iPhone XS
  • iPhone XS Max

同时,Max 首次登场,这一年苹果手机销量逆势反弹到 1662 亿美元。

同年,苹果更新了 iPhone 5c 的继承品——iPhone XR,但 R 从何而来,我们目前找不到一个特别自洽的解释,只能说苹果希望表明它是「X」字辈,但又要和 XS 区分开。

这里值得注意的是,对于如 iPhone 5S 的「S」,iPhone XR的「R」,苹果习惯于将这样位置的字母,虽然大写,但是用更小的字体来展示,并外接边框,突出强调。

如:iPhone XS

iPhone XS 的S实为大写,只是字号变小

还有更早之前的 iPhone 3GS:

iPhone 3GS 的S

到了 2019 年,苹果的新机命名又发生了变化,引入 Mac 经典命名 Pro,并将大屏旗舰从 Max 改名为 Pro Max。

  • iPhone 11
  • iPhone 11 Pro
  • iPhone 11 Pro Max

新引入的 Pro 接棒原来的 Plus,而 Max 特指屏幕大一号。

2020 年,在 11 以往产品线的基础上,又添加了 iPhone 12 mini,作为大屏时代下的小屏补充。

  • iPhone 12
  • iPhone 12 Pro
  • iPhone 12 Pro Max
  • iPhone 12 mini

至此,iPhone 的产品线稳定下来。从命名上,可以看到,iPhone 的产品比 Mac 更为混乱,只能说少有秩序。

iPhone家族史

在苹果召开的 2021 秋季新品发布会上,我们看到同样的命名延续下来,也就不意外了。

  • iPhone 13
  • iPhone 13 Pro
  • iPhone 13 Pro Max
  • iPhone 13 mini

不过,发布会讲到iPhone 13 部分时,我们发现一个小细节——Pro 更加自成系列。

首先,iPhone 13 mini 和 iPhone 13 放在一起讲解。接着单独讲解人、单独过场动画的 Pro 系列登场。

苹果品宣 13 Pro 的点还是性能(A15 Bionic)、相机(前置深感、3摄等)、耐用性(外观、耐磨、耐腐蚀)、屏幕(Promotion、Oled、XDR),来包裹 Pro系列的核心关键词——专业性。

除了这些基本的参数讲解外,13 Pro 还引入电影导演的拍摄场景,来向用户传达:iPhone Pro 系列不是手机、是能干活的摄像机。

至此,苹果从 iPhone 11 推出 Pro 系列,经过三代演变,将乔布斯当时定下的消费者命名「i」,硬拉到「Pro」级别。使用的方法也非常简单,就是在硬件与生态领先后,为消费者打造出一种使用消费级产品,也能产出专业级内容的向往。

这种向往非常有鼓舞性:

尽管我不是大导演,只是一个普通人,但只要我做一件事,就有成为他们的可能,那就是购买 iPhone 13 Pro。

至此,iPhone的产品可以分为普通消费:

  • iPhone 13 mini
  • iPhone 13

以及专业级向往:

  • iPhone 13 Pro
  • iPhone 13 Pro Max

iPad:最为混乱,反正 Pro、Air 用起来没区别

如果说 iPhone 的命名演进看起来稍微有点混乱,那见识到 iPad 之后,或许你就释然了。

iPad 可以说是所有苹果设备中命名最为混乱的产品线,从 2010 年的 iPad 到 2011年 的 iPad 2 还规律可循。

2012 年,iPad 3 被命名为「全新 iPad」,作为首款配备 Retina 显示屏的iPad。这样的名字也着实敷衍,在产品角度,iPad 3 为了强上 Retina 屏,续航、重量、处理器、图形性能都差强人意,于是仅仅在存活 7 个月后,iPad 4 快速迭代了出来,三代随之停产。

iPad 4 名为「配备 Retina 显示屏的 iPad」,同时发布的还有第一代 iPad mini,当时,两台设备3天内共售出300万台,表现着实不凡。

2013年,iPad Air 发布,外观的改变促成了本次对 MacBook Air 的借名,iPad Air 仅厚 7.5毫米,重量从上代的 652g 速降至 469g,同时借鉴 iPad mini 的窄边框设计让 Air 更加名副其实,转年推出 iPad Air 2。

2015 年,最被苹果报以「生产力」期望的 iPad——iPad Pro 登场,2017年,iPad 基础版命名再次出现,不过这个时候,苹果的产品线终于已经稳定下来,入门款 iPad、轻薄款 iPad Air,性能版 iPad Pro,以及 iPad mini 同台竞技。

2017 年是一个分界线,这一年,iPad 的所有产品线后面都不再带有数字,如新推出的 iPad 改为 iPad(第 五 代),iPad Pro(第 二 代),这种只写产品线本名,将第几代弱化到详细说明中附属括号的表现方式,苹果沿用至今。

苹果主宣传页面并无括号后缀(第几代)

为什么 iPhone 命名会将产品名+第几代数字连写,而 iPad 不会,反而弱化到括号中?

苹果主宣传页面则保留命名代数数字

或许是因为 iPhone 是以一年的更新频率规律更新,且随之附带的 Pro、Max 等也会随之相应规律更新。但 iPad 并不是这样,可能今年的 9 月更新 iPad Air,也可能转年的 3 月更新,也可能好几年都不更新。用户没办法通过数字快速知晓在售的这台 iPad 到底是哪年的新品,而且 Pro、Air、mini 的后缀数字也早已不在同一起跑线上了。这样一来,为何不直接去掉第几代,让消费者认为当下的这台就是最新款,无需对比历史机型。

于是,在 iPad 这一产品线上,苹果根据市场反馈,细分出 iPad 基础版、Air 轻薄版、Pro性能版、 mini 便携版。但在数字命名上,苹果选择了弱化第几代的方式进行呈现。

在 2021 年的苹果新品发布会上,iPad mini 6 如期而至,尽管我们这样叫,但在官网的显示上,也早已将第几代写入括号中,并且不在官网主页面展示。

不过这样的产品线,到底是以满足不同用户的使用场景,还是只为了制造阶梯价格区间,收获更多利润,苹果或许陷入了一个两难境地。就以 Air 和 Pro 为例,iPad Air、Pro 之间的差别显然不如 MacBook Air、Pro 之间那样清晰。(MacBook Air 代表更轻的重量、MacBook Pro 代表更强的性能)

在 iPad 上所表现的的,11 寸(三代) iPad pro 重量为 466g,稍微比 iPad Air(四代)458g 重 8g 而已,但是厚度上,Pro 反而要比 Air 还要薄 0.2 毫米。实在体现不出来 iPad Air 的 Air 在哪里,再加上 iPad Pro 强硬件+弱软件的大马拉小车现状,也难以配得上 Pro 的称谓。

这样一来,iPad 的产品线定位更像一种价格阶梯,入门买 iPad,稍微预算高一些买 Air,想一步到位则买 Pro,尽管这三者,在目前移动办公、娱乐的使用差距上,真的很难拉开太大差距。

可以看出,乔布斯的四象限命名,已经在 iPad(亦可延展到苹果整体产品线)渐行渐远,无论是苹果刻意或无意为之,其产品线命名都在向营收导向而转型,苹果确实仍关心细分消费人群,只不过是从之前关心术业有专攻的不同需求人群,转为关心你口袋里的钞票是一张、五张、还是十张。在这里不禁要为 Mac 担心,美妙简洁且对消费者友好的四象限命名方式,还能维持多久?

定位困局,苹果求变成功了吗?

作为一家崇尚简洁的公司,可以看出,苹果相比其他厂商的命名已是十分克制,甚至对比其他厂商,苹果已然做的不错。

比如在 Lenovo 官网,可以看到,笔记本阵容分为 Thinkpad、ThinkBook、YOGA、LEGION 等五大产品线,仅在 Thinkpad 产品线下,就有将近 9 大系列,可以说是笔记本领域拥有最多 SKU 的厂商之一。

仅仅1个产品线下,就有9大系列,消费者如何挑选?

苹果的一个理念就是崇尚简洁,这种理念贯穿于其产品及对外宣传上,不过从产品命名上,却感觉苹果每次都很难考虑周全,有时做的好,有时做的一般。

在这里暂且举两个产品线消亡的例子,来一窥苹果更名背后的深层次原因。

12 寸 MacBook,难逃历史的车轮

第一个要提的产品是 MacBook(不带后缀)。2015 年,苹果发布 12 寸全新 MacBook,主打轻薄,去除了一切旧的物理接口,只留下 3.5mm 耳机插口与 Type-C 接口,移除风扇,厚度锐减到  1.31厘米,重量不到一公斤。然后于 2019 年 7 月从官网下架,空缺以新款 MacBook Air 代替。

苹果为什么要在已有 MacBook Air 的前提下,还推出 MacBook?并且为什么推出 4 年后反而砍掉?这还要回到当时的历史背景中去。

说回 MacBook Air,Air 产品线刚面世时,是绝对的高端产品线,价格甚至超过 Pro。但随后,Pro的产品形态也逐渐变得轻薄,Air 也就随之沦为 MacBook 系列中的低端型号,Air 于是不再走轻薄路线,但没让苹果想到的是,Air 的销量一直都非常不错。

于是,苹果认为,是时候重拾轻薄路线了,而在定位上,自然不会低端,因此,12 寸 MacBook 随之而来。

MacBook 不带后缀的产品线也非首次,早在 2007 年,苹果就有俗称「小白」的同名 MacBook 低端产品线,而 2015 年,苹果只是把这个产品线重拾了起来,并做了定位高端的品牌升级。

2007年推出的「小白」MacBook

而更重要的一点是,苹果当时推出 12 寸 MacBook 契机也到了。

当年,intel 的超低功耗处理器走向成熟,这类 CPU 的明显特点是 TDP(热设计功耗)功耗仅 5-7W,且不带风扇,于是,苹果认为超低功耗 CPU 该崛起了,且非常适合极致轻薄设备。于是,苹果在机械结构、设计上做了很多努力,蝶式键盘的 MacBook 就与我们见面了。

而后其退出历史舞台,也有很多综合性因素,例如蝶式键盘口碑很糟,intel 不再强力,更重要的是 M1 的出现,让 Air 直接可以去掉风扇,变得更为轻薄。这就导致高端型号 12 寸 MacBook 并没有与低端型号 Air 拉开差距。存在感变得越来越低,从而退出历史舞台。

iMac Pro,并非 Mac Pro 竞对?

另一个消亡的产品线是 iMac Pro,不过提及它之前,不得不吐槽下 iMac 的命名,如果以当时乔布斯的意图,i 明显是赋予消费类电子产品的专属命名,如现在的 iPhone、iPad 等产品,像 iMac 这样强劲性能的产品,赋予 i 标签,或许只是一个权益之计。

2017年,苹果推出 iMac Pro,杂糅的命名(i、Pro并存)、强大的性能(浮点运算能力 24Teraflops)、不菲的售价(4万)2021 年初该款产品停售。

一种很流行的观点认为:iMac Pro 与  Mac Pro 是竞争关系,而大多数人用不上售价昂贵、性能溢出的 iMac Pro。

工作站级别iMac Pro

但这样的答案显然站不住脚。首先 iMac Pro 是一体机,定位更高,Pro 更像是四象限失效后,修饰 iMac 的形容词,定位于给需求更高的设计师使用。

而 Mac Pro 是工作站,定位于给像 使用 CAD 这样工业工程的专业级用户使用,而且设备可拆卸、可升级。

iMac Pro退出历史舞台的真正原因,还是因为 M1 的出现。苹果的野心是自己电脑全线配备 M1,但这真的很难。

苹果毕竟不是芯片公司,不可能为每一个产品线定制化芯片,所以我们看到 MacBook 全线+iMac 都用上了 M1。

但在 iMac Pro 工作站上,还能沿用 M1 吗?M1 再强,定位也只是低功耗处理器,TDP 顶天30 W,这和工作站的高性能还有一段距离, iMac Pro 需要的是 M1 X 这样的更强心脏,TDP 至少上百瓦才配得上工业级工作站的定位。

所以,在高性能芯片没出来时,iMac Pro 的定位着实尴尬,强上 M1也不是不行,只不过那就会和 iMac 的定位冲突了。

一种乐观的预测是: iMac Pro 只是暂时下架,等 M1 X 或是 M2 诞生,那就是它与消费级产品拉开性能差距,王者归来的时候。

我们可以发现,任何时刻,一个产品线的兴起和衰亡,与芯片更加息息相关,市场反馈则次之,要不就是出现了更强的芯片,可以让新产品线发挥垂直优势,要不就是合适的芯片还没有出现,只能先暂时别过。

内在革新 VS 外在创新

最后值得说道的还有 iPhone ,iPhone 作为目前苹果最为为大众所熟知的产品线,贡献的收入比例决定了苹果必须为该产品线分配更多的市场营销脑力与预算。

iPhone营收仍占苹果6成以上份额

而一年一更新的苹果或许早已知道,电子产品的更新换代率和自己开新品发布会的频率总是对不上的,「凑活能用」的人们总比「永远用最新」的人要多。

如何让这一部分人乖乖掏钱,可以说是苹果最为头疼的问题,那就再开拓新的产品线吧,顺便赋予一个全新的名字,这样总比简单的数字迭代要看起来有购买欲望。

2014 年,面对大屏手机竞争,苹果开启全新型号 iphone 6 Plus 对抗安卓阵营,2015 年,小屏 SE 面世,这一年,iPhone 总销量达到历史巅峰 2.312 亿台,销售额达到 1550 亿美元。可是随后的 6 年里,苹果再也没有超过这个数字,无论是新型号 mini、Pro、Max 轮番登场,销量上,截止到 2020 年,iPhone 持续下降 14%,这是因为来自中国的竞争对手小米、华为等过于强劲了。

我们之所以无法在 Mac 市场上看到同样的命名突破,或许是因为 Mac 只占苹果 10%-20%的收入比例,同时对于专业人群,新的产品线,人们可能也并不那么感冒。

直到 2020 年,M1 芯片横空出世,告别 intel 之后,苹果为旗下 MacBook、iMac 注入更强劲的芯片,以真正实力再次获得消费者的认可,而不是市场营销层面的文字游戏。

2020年推出M1芯片Mac后,苹果Mac销量明显上涨

这或许告诉我们一个道理,尽管(内在本质)革新要比创新(外在方法)难,但想办法开拓更多的产品线,并赋予一个新名词,不如打磨好已有的产品线,能获得的认可会更稳定。

本文首发少数派,同步 WEB VIEW,感谢欧阳洋葱的内容支持。

❌