❌

阅读视图

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

数据说话：Go 1.26 或成近年来“问题最多”的大版本，现在升级安全吗？

✇Tony Bai
bigwhite

本文永久链接 – https://tonybai.com/2026/03/06/go-1-26-most-problematic-release

大家好，我是Tony Bai。

2026 年 2 月，Go 1.26 如约而至。伴随着 new(expr) 语法糖的引入、Green Tea GC 的全面转正，以及go fix 现代化重构等一系列重磅特性，许多 Gopher 都按捺不住尝鲜的冲动。

然而，在经验丰富的 Go 团队和架构师群体中，流传着一条不成文的“潜规则”：永远不要在生产环境第一时间升级 X.Y.0 大版本，至少等到 X.Y.1 补丁发布后再做决定。

这条潜规则并非空穴来风。Go 的 1.N.0 版本虽然经过了长达半年的开发和 RC 阶段的测试，但只有当它真正被全球几百万开发者投入到千奇百怪的生产环境中时，那些隐藏在深处的边界 Bug 才会浮出水面。而 1.N.1 版本，正是官方对这“第一波真实世界火力测试”所暴露问题的集中修复。

因此，一个非常客观且有趣的推论诞生了：观察 1.N.1 里程碑下的 Issue 数量，可以作为衡量 1.N.0 初始质量的一张“晴雨表”。

最近，我在例行了解 Go 官方仓库的 GitHub 里程碑数据时，发现了一个令人警惕的信号：Go 1.26.1 的 Issue 数量，正在呈现出明显的“异常峰值”。

本文将用真实的数据说话，带你横向拉网式对比 Go 1.17 到 Go 1.26 这五年间、共十个大版本的初期质量水平，并深度拆解这些 Issue 的具体成分。Go 1.26 到底稳不稳定？现在升级安全吗？答案就在这些数据里。

核心数据全景：Go 1.26 的“异常峰值”

为了得出客观的结论，我利用 GitHub cli端gh工具 提取了从 Go 1.17.1 到 Go 1.26.1 的完整里程碑数据。这跨越了 Go 语言 2021 年至 2026 年的五年黄金发展期。

为了更直观地感受这组数据的冲击力，我们将其绘制成趋势图（数据采集于 2026 年 3 月4日晚）：

从数据中读出的残酷真相

仔细审视这组数据，我们可以得出几个不容忽视的结论：

  1. 总量拉响警报：Go 1.26.1 的总 Issue 数目前已升至 39 个，直接打破了五年来历史最差的 Go 1.21.1 的记录（38 个）。这意味着它发布后暴露出的问题远超常规水平。
  2. 与“前任”形成鲜明对比：就在半年前发布的 Go 1.25，其 Go 1.25.1 补丁仅有 9 个 Issue，堪称近年来最稳定的“神仙版本”。Go 1.26 的问题数量是其四倍有余，这种断崖式的质量波动令人意外。
  3. 修复压力巨大：截至数据采集时，Go 1.26.1 仍有 17 个 Open Issue 亟待修复，官方团队正处于“救火”状态中，Go 1.26.1 补丁的发布可能还需要一些时间。

初步结论：Go 1.26 大版本的初始质量（Initial Quality）存在明显瑕疵，社区踩坑率偏高。


图Go 1.26.1 milestone下的issues列表

深度挖掘：为什么 Go 1.26 成了“重灾区”？

看到这里，你可能会问：Go 团队的开发流程一向严谨，为什么 1.26 会出现如此多的问题？

为了探寻真相，我没有停留在宏观数字上，而是将 Go 1.26.1 里程碑下的 全部 39 个 Issue 逐一扒开，按其性质进行了分类。不看不知道，一看吓一跳，这 39 个问题背后的成分大有玄机。

通过分类数据，我们可以清晰地看到导致 Go 1.26 翻车的“三大元凶”：

cmd/fix / modernize 相关：创新的“生长痛” (占比 33%)

这是 Go 1.26 核心新特性——全新的 go fix 自动代码现代化工具——直接引发的问题（约 13 个）。

静态分析并自动修改代码是一把双刃剑。在真实世界极其复杂的抽象语法树（AST）场景中，go fix 暴露出了一些“好心办坏事”的边界 Bug。例如：

  • stringsbuilder 重写规则破坏了某些合法代码。
  • rangeint 升级在某些跨平台场景下存在兼容问题。
  • minmax 替换规则意外破坏了 select 语句的结构。
  • waitgroup 检查器导致了误报的编译错误。
  • … …

好消息是：这个类别虽然问题多，但大多数是被工具链“误伤”的语法层面的问题，且 绝大部分已被 Go 团队快速修复（目前该类别仅剩少数处于 Open 状态）。这说明 Go 团队对新特性的反馈响应非常迅速。

compiler/runtime 相关：最令人担忧的核心动荡 (占比 44%)

这是本次分析中最令人担忧的类别。多达 17 个 Issue 直指 Go 的心脏——编译器和运行时。

引入 Green Tea GC 全面转正、栈分配优化以及实验性的 SIMD 等底层变动，不可避免地触碰了最敏感的神经：

  • 出现了多个 Internal Compiler Error (ICE)，这意味着编译器在处理特定代码时直接崩溃了。
  • 曝出了 runtime segfault / panic，这是运行时层面的致命错误。
  • 32 位架构上的 timespec 定义错误。
  • SIMD 实验特性的相关 Bug。

这些直击核心的问题中，有大约一半目前仍处于 Open（待修复）状态。底层 Bug 的修复往往需要极其谨慎的测试和论证，这可能会直接影响 Go 1.26 在高并发、复杂内存场景下的稳定性。

Regression (回归问题)：亮起最高级别的红灯 (占比 10%)

虽然只有 4 个 Issue 被打上了 regression（回归）标签，但这是最严重的信号。回归意味着：在 Go 1.25 中能够正常编译和完美运行的代码，在什么都不改的情况下，升级到 Go 1.26 后却出错了！

这打破了 Go 最引以为傲的“向后兼容”承诺。这些回归问题包括：

  • Synology Linux 环境下 fork syscall 发生冲突。
  • 32 位 Android 系统下的 seccomp 问题。
  • mipsle 架构下出现的 segfault。
  • Windows 平台上 os.RemoveAll 行为异常（已修复）。

4 个 regression 问题中有 3 个至今尚未修复（Open）。这意味着，如果你恰好使用了相关的平台或系统接口，升级 Go 1.26 后将掉入一个“大坑”。

数据背后的真相总结

综合以上硬核拆解，我们得到了一张更为清晰的“风险热力图”：

理性决策：现在该升级 Go 1.26 吗？

数据虽然冰冷，但它为我们的技术决策提供了极其理性的支撑。面对目前 Go 1.26 这样一份成分复杂的“体检报告”，我为不同场景的开发者提供以下实操建议：

场景一：公司核心生产环境

强烈建议：暂缓升级，绝对按兵不动！

不要拿核心业务去为新编译器和新 Runtime 做“小白鼠”。鉴于存在多个未解决的 Compiler/Runtime Bug 和严重的 Regression 问题，至少要等到 Go 1.26.1 正式发布，仔细阅读其 Release Notes 确认相关雷区被排除后，再做评估。如果可能的话，我甚至建议那些对稳定性要求极高的金融或电商系统，等到 Go 1.26.2 发布后再进行灰度迁移。

场景二：团队的辅助工具 / 内部系统

建议：可以在本地或测试环境准备迁移，但不要上生产。

现在是让团队架构师开始在本地测试 Go 1.26 兼容性的好时机。你可以利用这段时间跑一遍全量的单元测试和集成测试，看看新的 Green Tea GC 是否对你们的特定负载有负面影响，或者有没有踩中那几个未修复的 Regression 雷区。

场景三：个人项目 / 新技术学习

建议：大胆升级，享受新特性。

对于没有历史包袱的个人项目，new(expr) 和强大的 go fix 绝对值得立刻体验。遇到 Bug 怎么办？去 GitHub 提 Issue！这也是参与开源社区建设、为 Go 生态排雷的绝佳方式。

小结：读懂版本号背后的语言演进

软件工程没有魔法，没有哪个大版本能在经历了底层大换血后依然完美无瑕。

Go 1.26.1 高达 39 个的 Issue 数量，以及占比极高的底层 Runtime/Compiler 报错，并不是在说“Go 团队不行了”，而恰恰反映了这门语言仍在保持着极其旺盛的生命力、以及为了追求更高性能而积极重构底层债务的勇气。

只不过，作为一线开发者和架构师，我们需要学会读懂这些数据发出的信号。在“享受技术红利”和“保障业务稳定”之间，让数据帮助我们找到最完美的平衡点。

最后，做个小调查：你目前在使用 Go 的哪个版本？是否有计划在近期升级到 1.26？欢迎在评论区分享你的看法！

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

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

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

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

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

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

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

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

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

© 2026, bigwhite. 版权所有.

🔲 ☆

Go 1.26 发布在即，为何 json/v2 依然“难产”？七大技术路障全解析

✇Tony Bai
bigwhite

本文永久链接 – https://tonybai.com/2026/02/11/go-1-26-json-v2-delay-7-technical-roadblocks

大家好，我是Tony Bai。

Go 1.26 预计将于本月（2026 年 2 月）正式发布。然而，在即将到来的 release notes 的欢呼声中，有一个备受瞩目的名字依然带着“实验性”的标签躲在 GOEXPERIMENT 背后——那就是 encoding/json/v2。

作为 Go 生态中最核心的基础设施之一，JSON 库的每一次呼吸都牵动着数百万开发者的神经。从 v1 到 v2，不仅仅是性能的提升，更是一场关于API 设计哲学、向后兼容性与极致性能的艰难博弈。

很多人以为 v2 的延迟是因为“官方动作慢”或“设计理念之争”。但当我们深入 json/v2 工作组的看板，剥开表层的讨论，会发现横亘在稳定版之前的，是七个具体而微、却又关乎全局的技术“钉子”。这些问题并非宏大的路线图分歧，而是关乎浮点数精度、错误处理语义、API 封装性等实打实的工程细节。

本文将基于最新的 GitHub Issues 讨论（截至 2026 年 2 月），带你通过显微镜审视这七大阻塞问题，一窥 Go 标准库演进背后的严谨与妥协。

七大阻塞问题（Blockers）一览

深度解析：魔鬼藏在细节中

1. API 设计的“丑陋妥协”：jsontext.Internal (#73435)

在当前的 encoding/json/jsontext 包中，竟然存在一个导出的 Internal 类型。这在 Go 标准库的审美中，简直是“房间里的大象”。

jsontext 是 v2 引入的底层包，专注于 JSON 的语法解析（Tokenizing），而上层的 json 包负责语义绑定（Binding）。为了让上层包能够访问底层的缓冲区或状态机，当前的实现不得不导出一个 Internal 符号。

这违背了 Go 标准库的黄金法则之一：公共 API 必须是为用户设计的，而不是为实现者自己设计的。

Joe Tsai (dsnet) 提出了一种解决方案：将 jsontext 的核心逻辑移入 encoding/json/internal/jsontext，然后通过类型别名（Type Alias）在公共包中暴露 API。然而，这带来了一个新的难题：godoc 对类型别名的支持并不友好，生成的文档可能会让用户感到困惑，因为方法都挂载在内部类型上。

这个问题已经上升为工具链生态问题。如果这个问题不解决，v2 发布后将面临两个风险：要么用户依赖了这个“临时” API 导致未来无法修改，要么标准库留下了一个永久的“伤疤”。

2. 致命的递归：当 Unmarshaler 遇到指针 (#75361)

这是一个真实且诡异的 Bug。一位开发者在迁移旧代码时发现，以下模式在 v1 中正常工作，但在开启 GOEXPERIMENT=jsonv2 后会导致栈溢出（Stack Overflow）：

type MyType string

// 自定义 Unmarshal 方法
func (m *MyType) UnmarshalJSON(b []byte) error {
    // 试图通过定义一个新类型来“剥离”当前类型的方法，以回退到默认行为
    type MyTypeNoMethods *MyType
    var derived MyTypeNoMethods = MyTypeNoMethods(m)

    // v2 在这里会错误地再次识别出 derived 拥有 UnmarshalJSON 方法
    // 从而导致无限递归调用自己
    return json.Unmarshal(b, derived)
}

在 v1 中，开发者习惯通过类型转换来“剥离”自定义方法。但在 v2 中，为了修复 v1 中某些指针方法无法被调用的 Bug（如 #22967），引入了更激进的方法集查找逻辑。

v2 的逻辑是：只要这个值的地址（Addressable）能找到 UnmarshalJSON 方法，就调用它。在上面的例子中，derived 虽然是新类型，但它底层的指针指向的还是 MyType，v2 过于“聪明”地认为应该调用 (MyType).UnmarshalJSON，结果造成了死循环。

这是一个典型的“修复了一个 Bug，却引入了另一个 Bug”的案例。Go 团队目前倾向于保留 v2 的正确逻辑（即更一致的方法调用），但也必须为这种遗留代码提供一种检测机制。目前的计划是引入运行时检测或 go vet 检查，明确告知用户：请使用 type MyTypeNoMethods MyType（非指针别名）来剥离方法，而不是使用指针别名。

3. 浮点数的“薛定谔精度”：float32 (#76430)

下面是展示该问题的一段示例代码：

var f float32 = 3.1415927 // math.Pi 的 float32 近似值
json.Marshal(f)

输出应该是 3.1415927（保持 float32 精度），还是 3.1415927410125732（提升到 float64 精度以确保无损）？

Go v1 的 json 包为了兼容性，倾向于将所有浮点数视为 float64 处理。这导致 float32 在序列化时经常会出现“精度噪音”——那些用户并不想要的、只有在 float64 精度下才有意义的尾数。

然而，v2 的 jsontext 包默认使用 64 位精度。这导致了 json.Marshal（上层）和 jsontext.Encoder（底层）在行为上的不一致。

  • 用户期望：float32 就该像 float32，短小精悍。
  • 技术现实：JSON 标准（RFC 8259）并没有区分浮点精度。
  • 性能视角：处理 32 位浮点数理论上更快，但需要专门的算法路径。

Go 团队正在考虑引入 Float32 构造器和访问器到 jsontext 包中，并修改底层的 AppendFloat 逻辑，以支持显式的 32 位浮点数格式化。这不仅是为了“好看”，更是为了数值正确性——避免“双重舍入”（Double Rounding）带来的微小误差。

4. 选项系统的“任督二脉”：透传难题 (#76440)

你调用 json.Marshal(v, json.WithIndent(” “)) 很爽，但如果你想控制底层的 jsontext 行为（比如“允许非法 UTF-8”或“允许重复键名”），你发现：顶层函数把路堵死了。目前的 MarshalEncode 只接受 json.Option，不接受 jsontext.Option。

v2 将 json（语义层）和 jsontext（语法层）拆分是架构的一大进步。但这也带来了配置穿透的问题。

如果为了保持 API 纯洁，强迫用户必须先创建一个 jsontext.Encoder 并在那里配置选项，再传给 json.MarshalEncode，那么 99% 的简单用例都会变得无比繁琐。

Go团队给出的提案是打破层级隔离，允许 json.Marshal 等顶层函数直接接受 jsontext.Option。这是一个实用主义战胜洁癖的胜利。

5. 功能做减法：unknown 标签的存废 (#77271)

v2 曾引入了一个 unknown 结构体标签，用于指示某个字段专门用来捕获所有未知的 JSON 字段。同时，还有一个 DiscardUnknownMembers 选项用于丢弃未知字段。

dsnet（Joe Tsai）发起提案，建议删除两个功能。理由如下：

  1. 功能重叠：v2 已经引入了 inline 标签，它与 unknown 的行为非常相似，仅仅是语义上的微小差别（是否包含“已知”字段）。这种微小的差别会让用户感到困惑。
  2. API 极简主义：如果用户真的需要处理未知字段，可以通过自定义 Unmarshaler 来实现，或者利用 inline 标签配合后期处理。
  3. 向后兼容的智慧：添加功能永远比删除功能容易。现在删除，未来如果真有需求还可以加回来；但如果现在保留，未来想删就难了。

6. 控制流的缺失：SkipFunc (#74324)

json.SkipFunc 是 v2 引入的一个 Sentinel Error，用于告诉编码器“跳过当前字段/值”。目前它只能在 MarshalToFunc（用户自定义函数）中使用。但如果我在类型的方法 MarshalJSONTo 中想跳过自己怎么办？目前是不支持的。

这是一个典型的“二等公民”问题。用户自定义的函数拥有比类型方法更高的权限。这导致在迁移旧代码时，如果要实现“条件性跳过”，必须写出非常丑陋的 hack 代码（比如定义一个空结构体来占位）。

允许 MarshalJSONTo 返回 SkipFunc 看似简单，但它要求调用者必须处理这个错误。这意味着不能直接调用 v.MarshalJSONTo，而必须通过 json.Marshal 来调用，否则你会收到一个未处理的错误。这需要文档和工具链的配合。

7. 文档真空：新接口的最佳实践 (#76712)

v2 引入了 MarshalerTo 和 UnmarshalerFrom 两个高性能接口，它们直接操作 jsontext.Encoder/Decoder，避免了内存分配。但是，到底该什么时候用它们？

目前缺乏明确的文档指导。如果用户在任何时候都直接调用 v.MarshalJSONTo(enc)，可能会绕过 json.Marshal 中处理的许多全局选项（如大小写敏感、省略零值等）。

Go 团队计划在文档中明确：这属于“高级 API”，普通用户应始终使用 json.Marshal，除非你在编写极其底层的库。

路线图：我们何时能用上“真v2”？

根据最新的工作组纪要和 Issue 状态，我们可以画出一条清晰的时间线：

  • 当前 (Go 1.26, 2026.02)：GOEXPERIMENT=jsonv2 继续存在。v2 代码库已进入主仓库，但 API 仍未冻结。此时适合库作者进行集成测试，但不建议在生产环境核心业务中大规模铺开。
  • 决战期 (2026 H1)：必须彻底解决上述 7 个 Blocker。特别是 API 签名相关的修改（如 float32 支持和 SkipFunc），一旦定型就是 10 年承诺。
  • 目标 (Go 1.27, 2026.08)：如果一切顺利，我们有望在今年 8 月发布的 Go 1.27 中，看到移除实验标签、正式可用的 encoding/json/v2。这意味着 Go 语言将迎来其历史上最大规模的标准库升级之一。

小结：给 Gopher 的建议

  1. 别急着重构：现有的 encoding/json (v1) 依然稳健。除非你有极端的性能需求（v2 性能提升显著）或需要 v2 独有的某些特性，否则请按兵不动。
  2. 关注 jsontext：即使不用 v2 的序列化，新独立的 jsontext 包也是一个处理 JSON Token 流的神器，非常适合写高性能的底层解析工具。它的 API 设计比 v1 的 Scanner 更加现代化和高效。
  3. 参与反馈：现在是影响 Go 未来 10 年 JSON 处理方式的最后窗口期。如果你对上述 Issue 有独到见解，去 GitHub 上发声吧！

Go 团队的“慢”，是对生态的“敬”。这七个拦路虎，每一个都是为了让未来的十年里，我们能写出更少 Bug、更快速度的 Go 代码。好事多磨，让我们静候佳音。

参考资料

  • json/v2 工作组的看板 – https://github.com/orgs/golang/projects/50
  • encoding/json/v2: working group meeting minutes – https://github.com/golang/go/issues/76406

你更在意什么？

Go 团队为了 API 的洁癖和严谨，宁愿让 json/v2 多飞一会儿。在你的开发实践中，你更倾向于“尽快用上新特性”，还是“哪怕慢一点也要保证接口设计的绝对完美”？你对 float32 的精度噪音有切肤之痛吗？

欢迎在评论区分享你的看法，我们一起坐等 Go 1.26 官宣！

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

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

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

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

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

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

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

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

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

© 2026, bigwhite. 版权所有.

🔲 ☆

Go 官方密码学原则：为什么 Go 的 Crypto 库难以被“用错”？

✇Tony Bai
bigwhite

本文永久链接 – https://tonybai.com/2026/01/18/go-cryptography-principles

大家好，我是Tony Bai。

在软件工程领域，密码学（Cryptography）通常被视为“高危禁区”。大多数语言的建议都是“不要自己写密码学代码”，甚至“不要自己组合密码学原语”。

然而，Go 语言打破了这一魔咒。Go 的标准库 crypto/… 以及扩展库 golang.org/x/crypto/… 被公认为业界最安全、最易用的密码学实现之一。这并非巧合，而是源于 Go 官方制定并严格遵守的一套《密码学设计原则》。

这份由前 Go 安全负责人 Filippo Valsorda 撰写的文档，确立了四个核心支柱，按优先级排序依次为：Secure（安全）、Safe（稳健）、Practical（实用）和 Modern（现代）。

今天，我们深入解读这四大原则，并结合代码示例，看 Go 是如何将这些原则转化为代码的。

img{512x368}

原则一：Secure（安全实现）

定义： 库的实现本身必须没有安全漏洞。

这听起来像是废话，但在密码学中，”没有漏洞”不仅仅意味着逻辑正确，还意味着要防御侧信道攻击（Side-Channel Attacks）。Go 团队为了达成这一目标，宁愿牺牲一部分性能，也要保证实现的低复杂度和高可读性。

Go 的实践：恒定时间比较

攻击者可以通过测量函数执行的时间长短来推测密钥信息。为了防御时序攻击，Go 在 crypto/subtle 包中提供了恒定时间（Constant-time）操作原语。

示例代码：

在验证 HMAC 签名或哈希时，绝不能使用普通的 == 或 bytes.Equal，因为它们一旦发现字节不匹配就会返回，导致耗时不同。Go 提供了 subtle.ConstantTimeCompare。

// https://go.dev/play/p/TJkuUTcv9Ta
package main

import (
    "crypto/hmac"
    "crypto/sha256"
    "crypto/subtle"
    "fmt"
)

func CheckMAC(message, messageMAC, key []byte) bool {
    mac := hmac.New(sha256.New, key)
    mac.Write(message)
    expectedMAC := mac.Sum(nil)

    // ❌ 错误做法：return string(messageMAC) == string(expectedMAC)
    // 这种比较会因不匹配位置的不同而耗时不同，泄露信息。

    // ✅ 符合 Secure 原则的做法：
    // 无论内容如何，执行时间恒定，杜绝时序攻击。
    return subtle.ConstantTimeCompare(messageMAC, expectedMAC) == 1
}

func main() {
    key := []byte("secret-key")
    msg := []byte("hello world")
    // 假设这是收到的签名
    mac := []byte{0xde, 0xad, 0xbe, 0xef} 

    if CheckMAC(msg, mac, key) {
        fmt.Println("Valid")
    } else {
        fmt.Println("Invalid")
    }
}

原则二：Safe（防误用设计）

定义： 库不仅要“可以”被安全使用，更要“难以”被不安全地使用。

这是 Go 密码学库最令人称道的地方。原则指出：默认行为必须是安全的，任何不安全的功能如果必须存在，必须在 API 命名上进行显式确认。

Go 的实践：TLS 证书校验

在很多语言中，关闭 HTTPS 证书校验可能只是一个布尔值 verify=false，这容易被开发者在调试后遗忘。但在 Go 的 crypto/tls 中，要跳过证书校验，你必须设置一个名字“长得吓人”的字段：InsecureSkipVerify。

示例代码：

// https://go.dev/play/p/aq2RARNHCgo
package main

import (
    "crypto/tls"
    "net/http"
)

func main() {
    // 默认情况下，http.Client 会严格校验服务端证书，这是“Safe”的默认行为。

    // 如果你非要关闭校验（例如自签名证书测试），你必须显式写出 "Insecure"（不安全）这个词。
    tr := &http.Transport{
        TLSClientConfig: &tls.Config{
            // ✅ 符合 Safe 原则的做法：
            // 强迫开发者在代码中承认“我在做不安全的事”。
            // 这在代码审查时非常显眼。
            InsecureSkipVerify: true,
        },
    }

    client := &http.Client{Transport: tr}
    _, _ = client.Get("https://self-signed.badssl.com/")
}

此外，Go 的 crypto/rsa 包在加密时，必须传入随机数生成器（io.Reader），这强迫用户思考随机源的问题，而不是在库内部悄悄使用伪随机数。

原则三：Practical（实用主义）

定义： 专注于解决大多数开发者的常见需求，而非学术研究或冷门场景。

Go 的目标是构建应用程序，而不是密码学测试工具。因此，Go 标准库会拒绝那些并未广泛采用的算法，优先支持互操作性强的标准。

Go 的实践：开箱即用的密码哈希

存储用户密码是 Web 开发最常见的需求。Go 在扩展库中直接提供了 bcrypt 包，这是一个久经考验的、针对密码存储优化的算法。它隐藏了盐（Salt）的生成和管理细节，提供了一个极其简单的接口。

示例代码：

// https://go.dev/play/p/BWg0HHxwBso
package main

import (
    "fmt"
    "golang.org/x/crypto/bcrypt"
)

func main() {
    password := []byte("mySuperSecretPassword123")

    // ✅ 符合 Practical 原则的做法：
    // 开发者不需要懂“加盐”、“迭代次数”等细节，
    // GenerateFromPassword 会自动生成随机盐并包含在结果中。
    hashedPassword, err := bcrypt.GenerateFromPassword(password, bcrypt.DefaultCost)
    if err != nil {
        panic(err)
    }

    fmt.Println("Hash:", string(hashedPassword))

    // 验证也同样简单
    err = bcrypt.CompareHashAndPassword(hashedPassword, password)
    if err == nil {
        fmt.Println("Password match")
    }
}

Go 没有强迫开发者去组合 SHA256 和 Salt，而是提供了一个实用、完整的解决方案。

原则四：Modern（拥抱现代标准）

定义： 提供当下最好的工具，并及时淘汰过时的技术。

“现代”不代表“实验性”。Go 会在算法成熟并被广泛接受后迅速跟进，同时对老旧算法（如 RC4、DES）标记为“弃用”（Deprecated）。

Go 的实践：ChaCha20-Poly1305 与 Ed25519

当移动设备崛起，且 AES 在无硬件加速（AES-NI）的设备上性能不佳时，Go 迅速在标准库和扩展库中引入了 ChaCha20-Poly1305 流加密算法和 Ed25519 签名算法。它们不仅速度快，而且比 RSA/AES 更难用错。

示例代码：使用 Ed25519 进行签名

Ed25519 是现代公钥签名的杰出代表，它不需要在签名时传入随机数源（避免了索尼 PS3 私钥泄露那样的随机数重用灾难），且公钥极其短小。

// https://go.dev/play/p/W9kRS6Ipm2h
package main

import (
    "crypto/ed25519"
    "crypto/rand"
    "fmt"
)

func main() {
    // ✅ 符合 Modern 原则的做法：
    // 引入现代、高性能、难以误用的算法。
    // Ed25519 生成密钥极快，且签名过程是确定性的，不需要随机数源。
    publicKey, privateKey, _ := ed25519.GenerateKey(rand.Reader)

    message := []byte("Go is modern")

    // 签名
    signature := ed25519.Sign(privateKey, message)

    // 验证
    isValid := ed25519.Verify(publicKey, message, signature)

    fmt.Printf("Signature Valid: %v\n", isValid)
}

值得一提的是，Go 在后量子密码学（Post-Quantum Cryptography, PQC）的支持上也走在了前列。

随着 NIST 标准化流程的推进，Go 迅速在标准库（Go 1.24+）中引入了 crypto/mlkem 包，支持 ML-KEM（即 Kyber）密钥封装机制。

更符合 Modern 原则的是，Go 的 crypto/tls 在握手过程中默认启用了 X25519Kyber768Draft00 混合密钥交换。这意味着，开发者往往无需修改一行代码，现有的 Go 应用就已经具备了防御未来量子计算机攻击的能力。这种“静默升级”正是 Go 密码学库现代化的最佳注脚。

小结

Go 的密码学库之所以强大，是因为它懂得克制。

  1. Secure：宁可慢一点，也要防止侧信道攻击。
  2. Safe：把“坑”填上，或者在坑边竖起巨大的警示牌（命名）。
  3. Practical：解决实际问题，而不是炫技。
  4. Modern：与时俱进，让开发者默认用上最好的算法。

对于 Go 开发者而言，最重要的一条建议是：信任标准库，不要自己造轮子。 因为标准库背后的这些原则，是你应用安全最坚实的护盾。

参考资料：https://golang.org/design/cryptography-principles

你的“加密”故事

密码学的坑，踩过一次就终身难忘。在你的开发生涯中，是否遇到过因为误用加密算法而导致的安全事故？或者，你对 Go 这种“保姆式”的 API 设计有什么看法？

欢迎在评论区分享你的“血泪史”或设计心得！ 让我们一起构建更安全的数字世界。

如果这篇文章让你对 Go 的安全性有了更深的理解，别忘了点个【赞】和【在看】，并转发给你的团队，安全无小事！

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

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

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

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

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

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

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

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

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

© 2026, bigwhite. 版权所有.

🔲 ☆

AutoPlan - 自建B站挂机升级服务

✇ROYWANG
ROYWANG

今年2月15的时候发表过一篇文章：BilibiliTask– B站自动挂机升级脚本

由于作者已经删库跑路(bushi) 已经不再维护此项目，而项目是托管到 GitHub 上，又有随时被删库的风险，而且B站的登录信息存储在 GitHub 上总感觉不安全。

在 GitHub 上发现了一个新的项目，是基于 BilibiliTask 进行开发的。可以自建于自己的服务器，数据更安全，也可以分享给朋友一起使用。

您可以使用项目 Demo 进行自动签到。

Demo地址：AutoPlan Demo

项目简介

项目地址：AutoPlan

这是一个自动化的托管系统，目前支持网易云签到刷歌，bilibili赚经验+自动赛事预测，米游社原神签到。

已经实现的功能：

  • b站每日自动经验任务
  • b站赛事预测赚硬币任务
  • 网易云自动签到刷歌任务
  • 米游社原神签到领奖励任务以及米游币任务

详细可以查看项目地址

经过实际测试，这个项目在运行单个任务时，内存占用会到 500MB 左右，如果您的内存低于1G不建议您安装。

准备

由于 AutoPlan 基于 JAVA 开发，采用 MySQL 数据库存储数据，所以配置要求如下：

  • JDK 8或以上版本
  • MySQL 服务

本教程基于宝塔进行可视化操作搭建。

安装 Tomcat

由于使用宝塔，所以这里只需要安装 Tomcat 即可自动配置 JDK；

如您已安装 Tomcat 并且配置成功，则此步可以跳过。

在软件商店中搜索 Tomcat 进行安装，这里推荐安装 8.5

img

这样即可配置完成。

此处 MySQL 安装方式此处不再进行演示。

部署 AutoPlan

下载编译包

在 项目地址 中下载最新编译好的 JAR包。您也可以选择自行编译。

img

将下载好的 JAR包 上传到自定义的文件夹中。

img

新建 JAVA 站点

选择 网站->JAVA项目->添加JAVA项目，从而部署项目。

img

需修改的配置信息如下：

  • 项目jar路径：修改为自定义的路径名，并且选择上传的 jar包
  • 项目端口：自定义端口

其余配置可按需求修改，然后提交项目。

点击站点设置，设置域名，开启外网映射，并配置SSL。

img

新建数据库

选择数据库新建，输入配置信息后提交

img

此时需导入数据库文件，文件地址位于 项目仓库 中的 auto_plan.sql 文件，将仓库代码文件下载，然后将 SQL文件导入数据库。

img

配置 配置文件

在项目jar包同级目录中新建 application.yml 文件

img

需修改服务器端口以及数据库配置，文件具体配置如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
server:
   #服务器端口，此处端口号为创建站点时所设置的端口。
   port: 26666
spring:
   #数据库连接配置
   datasource:
      driver-class-name: com.mysql.cj.jdbc.Driver
      url: jdbc:mysql://localhost:3306/数据库名称?characterEncoding=utf-8&useSSL=false&serverTimezone=Asia/Shanghai
      username: 数据库用户名
      password: 数据库密码
   main:
      allow-bean-definition-overriding: true
   mvc: #静态文件
      static-path-pattern: /static/**
# actable自动建表
actable:
   table:
      auto: update
   model:
      #分号或者逗号隔开
      pack: com.oldwu.entity;com.oldwu.domain;com.netmusic.model;com.miyoushe.model
   database:
      type: mysql
   index:
      #自己定义的索引前缀#该配置项不设置默认使用actable_idx_
      prefix: INDEX_
   unique:
      #自己定义的唯一约束前缀#该配置项不设置默认使用actable_uni_
      prefix: INDEX_UNIQUE_
   # mybatis自有的配置信息，key也可能是：mybatis.mapperLocations
mybatis-plus:
   global-config:
     db-config:
       id-type: auto
   #mapper配置文件
   mapper-locations: classpath:mapper/*.xml,classpath:mapper/**/*.xml,classpath*:com/gitee/sunchenbin/mybatis/actable/mapping/*/*.xml
   type-aliases-package: com.oldwu.entity
   #开启驼峰命名
   configuration:
      map-underscore-to-camel-case: true
      #输出mybatis日志
#      log-impl: org.apache.ibatis.logging.stdout.StdOutImpl

img服务器端口及数据库配置信息需修改，其余信息可根据自定义修改

启动任务，即可打开网站，注册账户。

链接：https://youdomain.com/reg

img点击未启动，即可启动项目

打开网址，即可注册账号

img

修改账号为管理员账号。

修改数据库 sys_role_user 表中 sys_role_id 为 1即为管理员

img

配置账号，并使用

推荐使用 BILIBILI客户端 扫码登录，具体获取 B站 COOKIE 以及完成推送可以参考 BILIBILITASK – B站自动挂机升级脚本 这里不再赘述。

img

系统默认每天8点自动进行任务，如需修改可通过 自动任务管理 中的 B站自动任务修改。

img

后语

由于是第三方脚本，所以有大概率的封号几率，而且如果全部托管到一台服务器上，封禁概率会大大提高

强烈建议自建，如通过本项目造成的一切损失本人概不负责！请谨慎使用。

🔲 ☆

BilibiliTask - B站自动挂机升级脚本

✇ROYWANG
ROYWANG

B站如果正常使用，偶尔投币不投稿的话升级实在太过缓慢。。。今天在刷百度时偶然发现了一个项目，可以进行自动挂机升级，每天可以获得65点经验。

BilibiliTask

项目地址：BilibiliTask

特性

  • 自动获取经验(投币、点赞、分享视频)
  • 直播辅助(直播签到，自动送出即将过期的礼物)
  • 自动兑换银瓜子为硬币
  • 自动领取年度大会员每月权益(每月1号领取B币劵、权益礼包)
  • 月底自动用B币卷给自己充电(每月28号)
  • 月底自动用B币卷兑换金瓜子(每月28号)
  • 漫画辅助脚本(漫画APP签到)
  • 支持功能自定义(自定义投币数量，银瓜子兑换硬币开关等)
  • 账户失效提醒(发送到你的微信或者钉钉)
  • 增加用server酱推送运行结果到微信
  • 增加推送运行结果到钉钉

搭建

项目给了两种搭建方式，一种是直接托管到GitHub,一种使用的是使用Docker搭建，不过使用Docker搭建的话，管理起来太过麻烦。故此次演示的是直接托管到GitHub。

获取需要的参数

打开 Bilibili，按下F12–>Application–>Cookies–> “https://www.bilibili.com”,需要三个参数SESSDATA、bili_jct、DedeUserID。

img

将项目Fork到自己的仓库

打开项目地址 BilibiliTask 登录账号后点击 Fork 到自己仓库

img

将获取到的信息填写到Secrets，一共三个参数

img

点击 New repository secret 新建三个存储库信息

img

Name填写BILI_JCT、DEDEUSERID、SESSDATA，Value填写所获得的数据

运行

默认Actions处于禁止状态，在Actions选项中开启Actions功能，把那个绿色的长按钮点一下，开启运行。

img

点击 按钮开启actions (引用自作者教程)

默认push操作会触发工作流运行。打开README.md，将里面的 笑脸 删除一个即可。

img

删除笑脸后保存配置文件（引用自作者教程)

查看actions，显示对勾就说明运行成功了。以后会在每天的10：30执行，自动完成每日任务。

img

查看运行情况（引用自作者教程)

使用Telegram Bot推送到Telegram群组

创建Telegram Bot

发送 /newbot 到 @BotFather，并给这个机器人取一个名字，获取Telegram Bot Token

img

获取Telegram Bot Token

获取群组ID并将机器人加入其中

在搜索框搜索 你的机器人名字，添加进群组

img

将机器人添加至群组

向机器人发送 “https://api.telegram.org/bot你的botToken/getUpdates”，打开网址箭头为群组ID

img

获取群组ID

在Secrets中新增TELEGRAM_BOT_TOKEN、TELEGRAM_CHAT_ID将获取的数据输入到value

img

此处TELEGRAM_BOT_TOKEN value填写 bot token，TELEGRAM_CHAT_ID value填写群组ID

即可完成 Telegram Bot 推送

img

完成 TG 推送

配置文件说明

配置文件的位置在 src/main/resource/config.yml

img

🔲 ☆

连续三次系统升级，直到 v9.0.5

✇SEO 网站优化及网站推广
David Yin

今天考到 MovableType 有了新的版本，当前的版本是 v8.4.3。

而看了新闻稿，可以看到最新的版本有 v8.4.4，v8.8.1，还有 v9.0.5。

回顾了一下，前两天，先是发布了MovableType v8.8.0。同一天，也发布了 MovableType v9.0.0。

不过两天，就有了更新版本，主要是安全更新以及 bug fix。

于是刚刚就升级了三次，先是从 v8.4.3 升级到了 v8.4.4。

登陆到后台，没有什么区别。

接着更新到了 v8.8.1。

看上去，UI 也没有什么变化。

最后更新到了 MovableType 9.0.5

从 MovableType v9.0 可以看到 UI 也有了很大的变化。需要一些时间来学习与消化。

先这样。

🔲 ☆

如何升级 Kubernetes 节点的 cgroup 版本

✇陈少文的博客
微信公众号
1. cgroup v1 与 v2 接口路径差别 v1 1 2 3 4 /sys/fs/cgroup/cpu/cpu.cfs_quota_us /sys/fs/cgroup/cpu/cpuacct.usage /sys/fs/cgroup/memory/memory.limit_in_bytes /sys/fs/cgroup/memory/memory.usage_in_bytes v2 1 2 3 4 /sys/fs/cgroup/cpu.max /sys/fs/cgroup/cpu.stat /sys/fs/cgroup/memory.max /sys/fs/cgroup/memory.current cgroup v2 是 v1 的升级版本，具有更统一的资层级管理、精准的资源隔离等优点。但也导致了，写代码时，读取相关接口文件时路径不一样，需要做兼容处理。另外，一个思路就是，统一到一个 cgroup 版本。 Kubernetes 默认支持
🔲 ⭐

英伟达黄仁勋CES霸气登场！鳄鱼皮夹克发售5090显卡，钱包快捂住还是准备剁手？

✇硕鼠的博客站
Luke Fan

黄教主已经在CES上吹响了号角，准备好钱包了没有？大家好，欢迎收听老范讲故事的YouTube频道。今天咱们来讲一讲CES上，全村最靓的仔黄仁勋。黄教主都发布了一些什么东西？我们是不是要准备好钱包去买东西了，还是说咱们稍微冷静一下？

现在AI嘛，市值最高的公司英伟达，作为英伟达的老板，黄仁勋在整个的CES大会上一定是最靓的仔。其他做AI的人，可能还没有他这么风光亮丽。为什么呢？因为CES呢叫做消费电子展，那些做云计算的人，你们靠后站。黄教主是要来发布游戏显卡的，他是来玩消费的，这个还是有很大差别的。而且整个的AIGC玩了两年多，唯一挣着钱的就只有黄教主自己了，其他人都在这赔本赚吆喝呢。所以呢，人家一定要风光亮丽的跟大家做一个演讲。

咱们先看一下皮衣教主，因为他走到哪穿个皮衣嘛。他这个皮衣呢，这一次是一件新皮衣，不是以前穿过的这些旧皮衣。这个叫Tom Ford设计的一个皮衣，这个皮衣呢叫鳄鱼皮印花皮夹克。就是我们可以看到这个皮夹克上有很多非常大的花纹，这个东西呢叫鳄鱼皮印花。就是你如果买了什么鳄鱼皮钱包或者是鳄鱼皮的皮鞋，上面就是这种大花。我还真没见过鳄鱼皮夹克，他这个皮夹克呢应该不是鳄鱼皮的，应该是牛皮的，只是呢把这个大花纹给你印上了而已。

但是这个夹克也不便宜了，8,990美金一件夹克。但是这个对于现在全世界市值最高的公司的创始人和CEO来说，不穿这样的夹克，估计也真的压不住场子了。首先上来讲的第一个，肯定还是数据中心业务。虽然这是消费电子展，但是数据中心业务才是英伟达现在真正的核心价值。那么消费电子展呢，游戏显卡是跑不掉的，5090这个一定要上来好好跟大家show一下50系显卡。

然后呢，是整了一个非常奇怪的新品，叫project DigITs。这个东西长得像Mac mini那么大的一个超强算力的AI主机，因为看Mac mini卖的很好嘛。

所以，要出来跟大家show一下。后边呢，还做了一些软件部分的发布，这一部分基本上可以忽略不计。至于其他机器人的部分呢，2025年我们看到成品满街跑的，这个可能性也不大，所以我们就后边省略掉了。

首先，黄教主上来以后，先举着一个大盾牌，把一堆的芯片拼成盾牌那么大，就像美队一样，举着个盾牌就上来了。这个东西是什么呢？叫Grace Blackwell NV link 72。当然了，GBNV link 72呢，长得并不是真的这个样子，他只是说跟大家表演一下这个东西，把芯片铺开了应该是这样。

英伟达的显卡一般叫B开头的呢，就是它的GPU，就是Blackwell框架，黑井框架。说B200、B多少，这就是GPU；G开头的呢，实际上是CPU，叫Grace。这个东西呢，是ARM的CPU。所以呢，这个叫GBNV link 72呢，就是36个Grace CPU，加上72个Blackwell的GPU拼在一起，加上这种高速连接，整个拼一块儿以后，做的一个高性能运算的主机。大家可以在这个上面去训练模型。

它呢，现在只是把这些东西都拼成了一个盾牌的样子，给大家看一眼。如果真的是一个这个GB 72这种东西的话，它是举不上来的，那个机器拼在一起是1.5吨。但是消费电子展呢，给大家看这个意思不大，看过了就知道了。

现在数据中心是谁是老大？今天的真正重头戏5090、5090D、5080、5070，也就是50系显卡。前面的40系显卡、30系显卡，我电脑上是一个3060，我儿子电脑上是4070。什么时候会去长这个数呢？就是他的显卡的架构换了。40系的是A系的显卡，叫ADA的这个芯片；到50系呢，就是B系列的，就是Blackwell黑井系列的这个显卡。

它按照黑井系列整个架构重新设计的，所以呢，5090、5090D、5080、5070这些显卡，大家可以认为，跟我们现在去买的什么GB200或者B200这样的GPU吧，是一样的这个架构。

5090跟5090D的差异呢，就是5090的就是为中国生产的阉割版本。就跟原来美国制裁中国，说你们不可以去用4090了，中国就开始卖叫4090D。D呢，现在有两种说法，一种呢说是叫精简的，还有一种说法呢是Dragon，就是专门为龙设计的这个芯片。就是它里面的CUDA的核心数量、连接的这个速度，以及里面的这个内存的大小和连接速度，都是受到限制的一个设备。

当然，即使受到限制了呢，它也要比这个传统的4090还是要快的。这就是5090和5090D。然后5080和5070呢，要比5090 GPU的扩大的核心要更少一些，而且呢价格也相对来说比较便宜。现在呢，很多人就觉得天塌了，为什么？因为显卡这个东西呢，其实一直是作为一种金融产品，或者叫理财产品来去处理的，它有很强的金融属性。而这一次呢，黄教主干了一个事情，就是降价。他的5090呢，其实降的并不多，应该比4090还要贵一些的，但是呢，他号称说5070价格还是非常便宜的。对于原来那些囤4090的人来说，这个天就塌下来了。

整个的性能来说的话，我觉得我们就没有必要去跟大家讲说，它到底有多少CUDA核心，怎么算呢，这个其实没什么意义。它里边做了一个新的东西，叫大力水手4DLSS 4，可以在显卡内部进行更多的这种直插帧的运算。游戏原来输出的比较低的帧率、比较低的这个分辨率的这个图片，它可以通过插帧、插分辨率的这些功能，让我们看到一个非常非常高帧率、非常清晰的一个画面，是他们真的这个新功能。而大力水手4必须在50系显卡上才可以走，而这个40系显卡最高可以看到大力水手3.5。如果想使用大力水手4，你就要老老实实的去买50系的显卡。

也是很多人在去批判，说黄教主你这个刀法实在是很精准，也是如此了。有多少人需要去买5090呢？其实原来买4090的这些人，在挖币已经过时之后，他们到底能不能把这个4090的钱挣回来，其实是很难说的。

虽然他有金融属性，但是原来主要是拿他挖币。以太坊已经不用4090去挖币了，人家换了新的这种凭证方式了。那么4090可能也就是说，第一个打游戏用，第二个呢，拿它去做一些本地的渲染，或者是本地的大模型，比如说Stable Diffusion。我在本地跑一跑，也就干一些这样的事情。

那么现在上5090到底有没有这个需求呢？其实这一块的需求和动力是不足的。为什么呢？就是你在本地去用这样的一个设备，你真的需要那么大的分辨率、那么高的刷新率，然后有那么好的游戏吗？其实没有。游戏跟显卡之间呢，都是矛跟盾的两面，要来回翻来翻去的。首先是游戏更新了，然后说OK，我们现在需要更好的显卡，否则的话这个游戏跑不到最高帧率。

现在这几年呢，其实游戏并没有这样的东西出来。可能大家可以去期待一下GTA6，当然GTA他们一般优化做得还可以，所以呢，未必需要这么高规格的显卡才能带得动他。可能3060、3070都可以跑得起来，因为做游戏的人他也想清楚说，如果我做一款游戏只有5090才能玩的话，那我这游戏能卖几套？而且呢，游戏如果帧率太高的话，其实人眼已经看不到了，所以这个帧率是有极限的。而这个分辨率呢，其实你到4K也算是到极限了，你再往上其实已经做不上去了。

所以现在呢，其实在游戏这一块上说，需求动力不是那么足。至于说从大模型或者这一块来说呢，更多的人还是愿意去使用像A100、H100这样的专门的算力卡，而不是说来去使用这种游戏显卡。因为游戏显卡其实它的设计侧重还是不一样的，你拿这种东西去做大模型的话，并不那么划算。

50系列呢，到1月30号，5090的这个显卡就可以在外面买到了，可能要到3月份5080、5070的这些显卡会逐步的面世。再往后一段时间呢，会出笔记本用的50系显卡。现在呢，像什么ROG，这个叫败家之眼，他们已经在开始官宣他们搭配50系列显卡的这些笔记本了。

我估计在买到差不多得到年中了吧。5月份才能买到，而且以英伟达这个显卡升级的速度的话，我觉得可能过一两年再去买这个东西，也还是来得及的。一般是说显卡提升了以后，这帮做游戏的再想一想，说：“哎，我是不是可以再去做一些更复杂的游戏出来？”慢慢地去淘汰这个低端显卡，一般是这样的一个情况。这是今年的重头戏。

5090再往后呢，就发布了一个很奇怪的东西，叫project DigITs。这个东西呢叫做数字项目或者数据工程。我估计黄教主呢也是看旁边苹果整的Mac mini M4出尽了风头，这么小的主机，这么强的算力。很多人把它买回来去做大模型，甚至把几台M4 mini的这个主机拼在一起，还可以跑一些更大的模型出来。黄教主说：“这个我也行的。”这种设备呢，从结构设计上，甭管是谁设计的，但是从生产上来说呢，一定是台湾或者是大陆的这些果链企业去生产的。所以黄教主说：“你们谁去给我整个这玩意出来？”这个应该并没有什么难度。

黄教主这个时髦肯定还要改一下。那么它这个里边使用的芯片是什么呢？叫GB10。G就是CPU，它里头是有ARM CPU的；B呢是Blackwell的这个算力芯片，也都在里面。但是呢，GB10是没法去打游戏的，它没有这个图像渲染的能力，或者说它图像渲染的性能并没有那么好。大家主要还是要用它去做数据分析，去做大模型的训练和推理。

这个机器有128G的统一内存，这个还是很贵的一个东西。因为像我们在苹果上买统一内存，那玩意简直像金子做的一样，非常非常昂贵。你说我升硬盘，这个价格还可以接受，但是你要想给苹果的Mac mini或者是MacBook这种容易升内存，那真的是肉都疼。它这个里边128G的统一内存，4T的存储，这块不太值钱。然后里边的操作系统呢，是英伟达自己定制的一个操作系统，在乌班图的基础上去改的一个Linux操作系统。据说呢是可以跑200B的模型，这个已经是非常非常吓人了。

像我现在的MacBook只能跑三十几B的，72B的已经跑不起来。他这可以跑200B的模型，如果把两台连接在一起，就直接可以跑405B。因为现在我们有一个405B的模型，就是Llama3 405B，你们两个串一块就可以跑了。这个还是很吓人的。

当然，价格呢，肯定也得对得起它这些高端配置，3,000美金可真的是一点都不便宜。Mac mini应该是500美金还是600美金开始吧，最高的这个款式大概可能到不了2,000美金。他这个直接上来就3,000美金，这个大家自己看着办。

但是呢，发布会上有一些东西是没说的。什么东西没说呢？就是这个设备的功率和散热到底怎么样，他没说。英伟达向来不是以省电著称的，英伟达一直都是非常非常耗电的。像我们前面讲的5090什么这种东西，经常是可能五六百瓦。但是他这样的一个GB10的芯片，塞了这么点的一个机器里头，到底是有多少功率？到底是需要配多大的风扇？这个东西能有多吵，大家可能心里要有一个准备。

当然了，你想3,000美金我都花了，如果想动小了的话，可能很多人会觉得我这个钱没有花到地方。我花了钱以后，第一个重量要够。这个英伟达的老黄还是非常非常有经验的。你们去看那个4090也好，5090也好，那个显卡那么老大个，你把这个显卡拿起来，也是贼沉贼沉的。为什么？因为都是巨大的散热铜管以及风扇，还有很多的金属散热片。所以那个东西非常非常的重。

现在它发布了这样的小型主机，这个到底有多重？到底有多么吵闹？大家自己去思考一下。还有一个问题他没说是什么呢？就是这个东西到底能不能出口中国，这事不知道。刚才5090的时候我们讲了，专门得设计一个叫5090D的东西，是可以出口到中国的。5090的咱们中国的游戏玩家们就别想了。project digITs到底能不能到往中国出口，还得要再等一等，看这个东西也没有那么快了，应该还要再等几个月。

现在我们就是看一个形状就可以了。那么好了，大家是不是应该把钱包掏出来看一看了？我们到底是不是应该要去买这些东西了呢？什么人真正适合去买这个 Project DigITs 呢？

第一个，如果你是有钱人，这个不需要理由，只管买就完了。哪怕买完了以后，你从来都不开机，供奉在那里没毛病。你说我为什么供奉这么个东西在那呢？为你这个仓里边的满仓英伟达股票去祈祷一下不好吗？英伟达这个发布会发完了以后，老黄直接身价上升了，因为股票在暴涨。他已经是世界市值第一的公司了，基本上股票还在三个点几个点蹭蹭涨上去，这是多么神奇的事情。

那你有钱人说我买一个摆家里供起来，没毛病。至于其他的人呢，就真的没必要买这东西了。为什么呢？首先要注意，它里边用的操作系统是一个拿乌班图修改过的定制操作系统，一个用户量不大的操作系统，各种兼容性问题可以把普通用户折腾死。如果你说我不是一个专门的工程师，我就是一个使用 Mac 的用户，或者使用 Windows 的这种桌面用户的话，你就别用这玩意了，这个不是一般人能搞得定的，只有工程师才可以使用这种定制操作系统。

为什么呢？因为它各种的软硬件的配套以及升级，还有这种兼容性都很麻烦。如果真的需要进行大模型训练或者数据分析，这些人说是不是应该去买呢？因为老黄在上面讲了说，我们就是为他们设计的。建议呢，你们还是老老实实的去买通道式服务器。就算你想在家里干这个事，你也去买那个通道式服务器。

为什么呢？因为通道式服务器和 Project DigITs 这种东西，它都是非常非常吵闹的。你要想发挥出这么多算力来，你再怎么设计，它这个功率还是在这的，还是要去散热的。那你干脆就用通道式服务器就完事了，就把它塞到车库、地下室、阁楼，反正这种地方，因为这样的东西，它不适合放在卧室、起居室或者是客厅里边，因为太吵了。而且呢，做这种大模型训练的人最好是用云端的服务器，不要放家里头。

就算是你的数据非常非常的保密，非常敏感，也不建议你在家里边去部署这种东西。为什么呢？因为咱们使用这样的设备呢，都是临时性的，不可能说我一天24小时不停地算这个东西，从来不停，这个事的可能性非常非常小。你可能连续算一周，或者算两周，算完了以后呢，你还是要停下来的。

如果用云计算的这个机房，你只需要为这一两周的时间买单，就可以了。剩下的时间你就不用管它了。那么云计算的这些服务商，就可以把这个主机租给别人了，这个还是非常开心的一件事情。那你说：“哎，我把这东西买回来搁这了。”那你如果不用的时候，难道不是觉得心疼吗？

像这样的主机，正常情况下，如果没有那么高负载的时候，可能也很安静。但是你一看到这个东西很安静的时候，你就想：“哎呀，我这3,000美金是不是花亏了呢？”家里的骡子和马都歇了，这事不行。他会有这样的心理矛盾在这里。

即使你真的是数据科学家，也必须要配一个IT维护工程师，否则你真的没法使这种设备。你就想吧，各种软件的安装，硬件的兼容，这个是很麻烦的。如果我们在云主机上用这个东西，我们是怎么来干这个事的？我们是使用刀客各种镜像来干活的。

这个什么意思呢？就是我们随时需要云主机的时候，我们去跟服务商说：“来，给我搞台新机器来。”然后他把新机器给你了，你就告诉他说：“请按照什么什么样的方式，给我把这个环境搭建好用。”用完了以后呢，说：“现在请回收这台主机。”这个主机就又变成干干净净的了。你下次什么时候再用，你再去跟他说：“哎，给我再去整一台空机器出来。”他再给你整一个干干净净的机器，重新部署。

这个是我们使用云主机的方式。但是我们要想一想，我们用桌面电脑是什么样的方式？那个电脑多长时间格式化一次，多长时间重装一次系统？像我们用麦克的这些人，可能三五年吧，会重装一次系统，这个是正常的。为什么呢？因为这个系统变化相对来说比较少，不会天天的变来变去的。但是这些数据科学家，可能今天我需要用一个这个插件，明天需要用一个那个组件。

这个东西还不停地升级。那你这个玩意儿怎么弄？你就需要不停地格式化电脑，不停地重装电脑。如果没有一个IT工程师跟着你的话，根本搞不定这个事情。就算是正常开机的云主机，我们多长时间格式化一次？可能真的是每个月或者每周，你都会去格式化它。为什么？因为我们需要去维护这个电脑，需要去升级系统。那升级系统你再看看，哎呀，这个升级的东西跟那个兼不兼容，不费劲啊，整个格式化干净，重新整一次就完事了。这是使用云主机的方式。所以没有工程师去维护的话，这个东西摆家里一点意义都没有。

那么最终的结论是什么呢？就是光鲜亮丽的小废物。这个project Digits就算是一个光鲜亮丽的小废物，非常非常贵。如果我们赶个时髦，整一个放家里头，摆起来供起来，平时也没有什么任务让它跑，这个没毛病。你只要有这个钱，没有人能够说你什么。如果你真的想用它，那就算了，趁早打消这个念头。

至于说5090这些东西呢，我觉得你如果真爱的话就去买。现在应该没有什么游戏是必须要5090才能跑起来的。如果你说我一定要去玩stable diffusion，去画一些画，或者我要去做一些渲染的话，哼，也建议用云主机，不要用5090这样的东西出来跑。

所以呢，现在英伟达发布的这些东西，建议大家谨慎购买。至于软件的部分，虽然现在英伟达也在努力的开源，就是他现在新出了一些东西，都是open source的，但是呢，英伟达的软件除非像CUDA那样，一开始在非常小众的领域里头深耕很多年，否则不建议大家去碰这个玩意儿。为什么呢？因为英伟达的软件，用户交互这块是比较差的。英伟达向来不以用户交互这个事情见长，他们都是一帮资深的黑客，一帮这样的工程师范的人。他们认为所有人都应该是工程师。你像刚才我们讲的这个project Digits，这样的东西，如果不是工程师，你根本搞不定这个东西。如果是我整这么一个东西，可能我也得平时把它放在柜子里。

需要去做一些模型。微跳模型训练的时候，把它请出来。机器格式化，整个重装好，然后把一个任务跑完了以后，再重新盖到盒子里头，装柜子里头完事。这个才是他的正常使用方式。等下一次再把他请出来的时候，重新再隔热化机器，重新装系统，这个才可以去正常工作。

所以呢，因为他向来不是给普通用户来用的。就算是你说：“哎，我游戏显卡，难道不是给普通用户用的吗？”是，但是你玩的是显卡的吗？不是，你玩的是游戏。游戏跟显卡之间还是通过各种SDK、各种程序接口在打交道。我们普通人，是不跟那个玩意儿打交道的。而且呢，所有短平快在热点上搞的软件，都不是英伟达擅长的事情。

所以软件呢，跟今天咱们讲的CES消费电子展，这个事就没有什么关系了。就算你说：“我是玩大模型的，我是科学家，我是工程师。”这个事情呢，你可以去进行部署，可以去使用。但是英伟达做的相应的软件呢，特别是在这种热门的领域里头，也建议大家先去使用其他家的，先别用他们家的。因为这些年来，在大模型里头推出的各种软件，其实都没有怎么流行起来。现在大家使的，其实依然是CUDA这个东西。一抽遭蛇咬，十年怕井绳。CUDA大家使习惯了以后，最后就没有办法被他绑架了，必须要使，因为大家继续使下去。

现在老黄就算是摆出再怎么人畜无害的这种表情来，也没有人敢用他们家东西，而且真的不好使。所以在这一块里头，有非常非常多其他公司的这种替代产品、替代的架构可以去用。

好，这就是今天咱们讲的英伟达。黄仁勋穿着他的印花鳄鱼皮夹克，给大家发布的这些东西。然后钱包呢，捂好了，稍微关注一下。特别是project Digits这样的东西，3,000美金对于我来说是比较贵了，可能对于很多人来说好像也不是很贵。但是你先想想你用的了这玩意不？你说如果我摆着，就是为了让英伟达的股票好好的再涨一涨，那你去买，其他的就先别买这东西了。

好，这期就跟大家讲到这里，感谢大家收听，请帮忙点赞，点小铃铛。

参加Discord讨论群。也欢迎有兴趣、有能力的朋友加入我们的付费频道。再见。

🔲 ⭐

撕开国内视频网站的4K迷雾：为什么你的4K视频还不如1080P清晰？影视飓风被下架的视频，撕开了国内视频网站的遮羞布

✇硕鼠的博客站
Luke Fan

中国的4K视频还没有1080P清楚，这到底是伤害了谁呢？大家好，这里是老范讲故事的YouTube频道。今天咱们要讲一讲，一条视频撕开了国内各视频平台遮羞布的故事。

这个视频呢，是影视飓风发的。影视飓风是国内专门做影视器材、影视技术推广和科普的一个顶级自媒体。咱们说他是自媒体稍微有点亏心，毕竟好几百人一公司，专门做各种影视设备和影视技术评测与科普的。这个公司呢，上架了一条视频，就抱怨说国内各个视频平台，他们的4K视频清晰度很烂，甚至还没有前两年他们推的1080P清晰度高。

所有视频都是糊的，或者看着很奇怪。而且，越是热门的视频，看的人越多，视频就越糊。这条视频出来以后，只用了一两天的时间，就被所有的平台全部下架，因为所有平台都在干这个烂事。但是呢，这一次声音并没有被压下去，很多的博主都上来声讨这些骗钱的视频平台。因为他们是按4K找我们收的钱，你给我看的视频还没有前两年1080P清楚呢，太过分了吧。

一方面是声讨他们，另外一方面呢，也在为影视飓风所鸣不平。那么到底发生了什么事呢？中国人都知道，4K肯定应该比1080P清楚。1080P就是1920乘1080的这个分辨率，4K呢，就是4块1080P的显示器拼在一起，横着是两个1920，竖着是两个1080，这样四个拼音块叫4K，应该是比1080P清楚4倍才对。

但是呢，我们不能光看分辨率，还要看什么？还要看码流。码流什么意思？就是一秒钟视频它的文件到底有多大，或者说那个数据包到底有多大。中国的视频网站呢，是给大家4K的分辨率了，但是呢，他们把码流压得比原来的1080P还低。一秒钟的视频里头，我就给你非常非常少的数据，然后让你去渲染4K的分辨率的这个画面。

那你说这玩意怎么渲染出来？其实很简单啊，咱们现在使用的，甭管是1080P还是4K，甭管是任何一种编码算法吧，咱们这叫有损压缩。什么叫有损压缩？就是压缩完……

这个视频在还原的时候，并不是完完全全还原回去的，而是有一些节点，有一些像素是算出来的。他不能保证跟原来完全一致。在有损压缩的情况下，到底损失多少呢？那我损失多一些，那我不是一秒钟可以发的，这个数据就少一些吗？我到那边去尽可能去算就完了。他通过这样的方式来实现。那么在有损压缩牺牲码流的情况下，甭管是4K、8K或者更高的分辨率，其实都是没用的。因为就传了这么多数据出来，到那头的解析器或者播放器解码的时候，巧妇难为无米之炊啊，你没法去把它解析得很清晰。

那为什么很多视频看着还很奇怪呢？因为这些视频网站用了一个比较缺德的算法，这个算法叫什么？叫锐化。什么叫锐化呢？它就是在这个分界线上，比如说你看这是我的脸，脸外面应该是切图切出去的部分。这一部分里头呢，它发现了这个图像的边缘，在图像边缘的地方增加对比度，让所有的图像边缘变得更清晰一些。这样的话，就可以在相对比较低分辨率的时候，让你觉得这个边都给我勾清楚了，都描清楚了。

所以他说很多的视频你看着虽然是4K，第一个很糊，一点都不清楚；第二个又觉得很怪，因为所有边缘的地方都给你勾个边。他通过这样的方式去欺骗广大的消费者，广大的订阅用户。那么你说有没有一些技术，可以说我把技术升级了，少一点码流，可以多一些清晰度呢？也有，但是中国的这些视频平台相对来说都喜欢用比较旧的技术。视频编解码技术其实也没有那么多种，咱们现在常见到的也就是H.264、H.265，谷歌自己家开源的WebM，也就是VP9，还有大家一起加盟的叫AV1，谷歌、微软、英特尔、英伟达、网飞等一堆人加盟了一个新的标准的AV1。

然后呢，是H.266。你说我们没见过这些东西，我们见过的都是MP4、MKV、M4V。这个里头是这样，大家现在看到的所谓MP4，其实就是H.264。那么你说这个H.265是不是MP5？不是啊。

我们有时候会看到它那个后缀是EIC，那个就是H.265。它们呢，压缩比会更高，但是呢，会更清晰。对于这种更高的分辨率的视频来说，会更适应H.264。其实对于4K视频，已经不是那么适应了，或者说它会有一些问题。而且H.264的压缩也没有那么高，因为同样的视频，你用H.265去压缩的话，它的这个尺寸是H.264的一半。

你比如说，就算是一部4K的电影，比如说90分钟电影，如果是H.264的话，它大概压完了以后应该是有40多G；你如果用H.265的话，大概是20多G。再往后呢，就是刚才我们讲了谷歌的VP9，这个呢其实除了谷歌自己之外，别人用得很少。咱们最多见到VP9的地方就是YouTube，YouTube里的大量视频，特别是4K视频，都是用VP9的。你下载下来的那个文件格式是WebM，这种格式呢，它基本上算法和整个的性能是跟H.265比较相近的。

然后AV1呢，是比WebM的VP9、比H.265还要再压缩得厉害一些，但是呢，这种压缩是不牺牲质量的情况下，通过更好的算法能够实现压缩。AV1呢，它可以把原来可能20多G的一部电影，变成十几G，可以再压小一半。但是AV1现在用得很少，国内的话就是爱奇艺和腾讯，号称要准备开始支持AV1了。国外的话，苹果、谷歌、Netflix都是AV1的。

然后H.266是最新的国际标准，这里头还有一点区别是什么，就是AV1是开源的，不用收专利费。剩下的H.264、H.265、H.266，这个由国际的IMPEC委员会、动态图像压缩委员会，大概是这样的一个名字，这些标准都是要收专利费的。国内的视频网站基本上都是用的H.264。那你说不对啊，他们想省带宽，使用AV1不就行了吗？它可以把视频压得更小，而且还很清楚。这是这样啊，天下没有白来的午餐。你想用更高算法的，或者更高技术规格的这个编码方式去编码视频的时候，你需要更高的编码算力。

原来，比如说我一台服务器，就可以对这个4K视频进行两倍速编码、三倍速编码。什么叫三倍速编码？就是原来，比如三个小时的视频，我一个小时给你编码完了，咱们就基本上认为它叫三倍速编码。但是呢，如果你用AV1，原来可能一个视频上来以后三个小时，你需要六个小时才能编码完成。他这个算力要求会上升很多。他通过这样的方式，把更多的信息隐藏在数据包里面去。

至于H266的话，现在刚开始去卖相关的专利和IP，还没有真正开始推起来。H266的算法应该会比AV1可能持平，或者比它稍微好一些，但现在用的人很少。为什么越热门的视频越糊呢？这个其实很多人很诧异。你按道理说，应该越热门的视频越清楚才对啊，大家都看同一个视频，那我这个视频缓冲一次不就对了吗？这个其实也很简单。你越热门的视频，它占用的带宽就越高，而在这个里边，真正费钱的不是存储空间，而是带宽。

所以，比如说今天有一个新的片子上来了，大家都要去看，那我们一定要尽可能地把这部片子压得更糊一些，让它占的带宽更少一些，才能够更省钱。否则的话，这个成本实在太高，受不了，这纯纯就是在骗钱。

那我们来分析一下视频平台关于视频分辨率的成本到底是怎么构成的。我们先想，我们上传一部视频。上传视频的时候，其实对于平台来说，他们只需要承担一个入口的费用，甚至这个可能都不是那么贵，因为我们上传视频并不要求完全实时，除非你直播。而且直播的话一般也就是1080P，不会给你做更高分辨率了。

上传完了以后，就是一个存储，我把它存下来就好了。对于视频平台来说，这个存储成本也是很大的一块钱，但对于它整体成本来说，相对占比比较小。再往后的一个巨大的成本是什么？是编码。你说我上传的就是4K MP4或者4K H265，为什么还要编码？你想，我们去看视频的时候，他会根据用户的带宽、用户的设备以及用户的付费情况，给用户不同的分辨率。所以他们去编码视频的时候……

会把我们上传的视频直接编码成，比如360K、480K、720P、1080P、2K、4K。它会把所有编码都编一遍，然后呢，还按不同的码流把它都编一遍，这样才可以在用户需要相应码流的时候，把相应的文件拉出来。

大家如果去看YouTube，或者看包括国内的一些视频网站的话，有一些专门的破解和下载软件。你把一个YouTube链接扔进去的时候，它告诉你说，我们现在从这个链接里头找到了一长串儿的URL，一长串儿的视频地址。它就是告诉你说，这个视频一共被压缩成了多少个分辨率。

我们经常去下YouTube上的这种长音乐视频，它那儿有4个小时、8个小时这种音乐视频。如果你是在很好的设备上放，你就可以下这种十几个G的版本，4K的。它一般下来是WebM的，从这个YouTube上下来。那你说，我就是想听个歌，我也不想看这个画，你就可以下这个单纯的音频，甚至说我可以下一个很低分辨率的视频的音频，可以下一个360P的，这个非常非常低分辨率。那个文件可能就几百兆就下来了。

整个的编码过程，其实是非常非常耗算力的，因为我们不停地上传视频，它就要不停地对所有上传的视频进行编码。甭管有没有人看这个编码的视频，比如说我上传了4K的，从来没有人看过这个4K的视频，它也需要重新编码一个4K，肯定是要在我那个基础上重新编码的，不会说拿我那个4K直接上去。

我一个4K 60帧的视频，上传到YouTube之前，应该是每20分钟17个G是这么大。我在本机编码完了以后，再上传的时候，20分钟大概就已经剩一半了，因为我是用本机的剪映重新编码一下，大概就剩个10个G左右。然后呢，10个G到了YouTube，你再从上面把4K视频再拉下来的时候，发现就剩4个G了。它一般是这样的一种编码方式，送上去，哪怕是从来没有人看过这个4K视频，它也会给你重新编码一下，然后变得小一些，统一的码流去处理。

当然你如果是放到B站上或者放到国内的这些视频网站上，你可能一个20分钟的4K 60帧视频，下载的时候估计也就剩下可能一两个G。这样一来，这事就是另外一个问题了。再下一个事是什么很贵呢？就是专利费。刚才我们讲了H.264，其实它因为比较旧了，它的专利费是比较便宜的。而且你买各种的编解码软件，买各种芯片的时候，它们都已经付过专利费了。

你说我做H.265，这个就要贵一些。你说我要用H.266，更贵啊。那你说我用AV1，那个便宜了。但是呢，你对于编码的算力，包括什么显卡，这些东西就都需要再增加的成本。现在支持AV1的，可能只有一些最新的显卡，以及最新的CPU，比如像苹果的这种M系列的CPU，它就会支持AV1。高通的8根2、高通888、高通8阵一都不支持。高通8根2是专门有AV1的硬编码的。

你说我没有这个硬编码，通过软件编码行不行？那个手机会冒烟的啊！那你说现在CPU，AMD也好，英特尔也好，只有最新的CPU才支持AV1的硬编码。而且它整个的算力成本是非常高的。所以国内现在用AV1的很少。就算是爱奇艺跟腾讯，也只是宣称了要用。真正我们现在在手机、平板上或者电视上想去看到AV1，还是比较难的。为什么？你把AV1弄下来以后，你到本地未必解码得开，或者你解码你只能进行软解码，就是通过CPU进行计算的解码，而不是说我这个CPU或者GPU里面有他的解码算法，有他这个解码芯片，然后我可以直接把他算硬解出来，还不是干这个。

所以他们现在也不太敢用AV1的东西出来，这个都是他们需要去思考的。存储其实成本不高，真正成本高的是带宽，CDN和宽带成本是高的。CDN叫什么？叫内容分发网络，就是它要尽量的让你在离你比较近的地方找到相应的资源，可以看到这个视频。因为我们看视频，希望能够连贯的把这个视频看完，不是说整个把它下载了以后再看，而是通过流的方式连贯的看。如果这个服务器离你很远，中间经过很多的节点……

你的传输速率就会非常不稳定，会来回抖动。那么他就不行啊，他一定要离你近的地方，重新再复制一遍这个视频，让你可以在离你最近的服务器上，尽可能尽量少的节点看到这个视频。这个成本是非常非常高的，对于视频网站，包括像直播网站，还有像什么抖音这样的网站，他们的成本最大的一块就是CDN成本。

那么中国为什么跟CDN成本这么死磕呢？一方面是咱们收的会员费低啊。你说我去跟YouTube、跟咕噜、跟HBO或者是网飞去比，大家收的会员费，中国基本上也就收了人一个零头。人家看一个月的钱，够咱看一年的，差不多是这么一个水平，所以咱们没收着钱。

另外一头呢，中国的CDN成本是美国的三倍。为什么是这样的呢？咱们中国人那么有钱吧？原因呢有两个。第一个原因是中国的网络呢，是中国移动、中国联通、中国电信，是这样的三套网络。三套网络之间呢，并没有那么通畅，而且中国的网络之间的节点是隔离的，或者说它之间的这种联通的成本是很高的。你想让很多比较远的地方人看到你的内容，你就要在当地付两三套相应的CDN服务器，你才能让他看到。

所以如果你在电信的网络上布了一个服务器，他们在联通的网上看，那这事有可能他就需要绕一个很远的中央节点再绕回来，那成本就高去了。你必须要再弄一次。那你说还有双线机房，有这种双线机房，就同时插两根线的，那就更贵呗。就这么简单的一个问题。

所以中国第一个大的问题，就是中国的网络拓扑结构非常复杂。我们在盛大的时候就遇到这样的问题，你如果想让东北的人进来打游戏，你必须在东北专门设计设置机房，否则的话他就没法跟人打，因为他特别慢，他这个节点特别远，是在中国整个的互联网拓扑结构图的一个最边缘的地方。他要想到上海服务器，就非常非常麻烦啊。

第二个问题是什么呢？垄断。中国是三大运营商垄断了这价格，而且呢，谁可以去做这个网络，谁不可以去做网络，谁可以去申请到证书，这都是国家机关可去批准的。

普通人没法去搞这样的竞争，所以呢，他们整个都价格就很贵。没有竞争需求嘛，都是国家说了算，都是国家的生意。我不能让国有资产流失了，所以中国的CDN成本是比别人贵的。那么这些视频网站就很痛苦。一方面，我收的钱比别人少，就是人家零头；另外一方面，我需要承担的最大成本是别人的价格的三倍。我该怎么办呢？我就只能是上来骗吧。我收了你4K的钱，但只给你看最不清楚的1K的视频。

中国人呢，为了应对这种CDN价格成本的问题，也想出了很多的骚操作方式。像刚才我们讲的降画质，加这个锐化，都是他们想出的办法。然后还有一种奇葩的方法，什么叫PCDN呢？我不是要到你机房里去调这个数据吗？咱不费劲了啊，咱从你电视里调，或者从你家里的机顶盒里钓。我们从每一个节点往外钓这个内容，也可以。但是后来呢，是国家不允许这么干了。你必须是从别人的机房里边调。为什么呢？因为很多人抱怨说：“你看，我这家里头买了一谁家的电视，这个电视在我不开机的时候，还跑了大量的流量出去。”这个事实在受不了。而且我影响正常使用了。我平时在电脑上，或者在其他的设备上看一些视频，或者做一些工作的时候，变得很慢。我的带宽都被这些电视去给人做P2P节点去了，这个也很讨厌。

这个也是中国人想出来的应对CDN成本的一些奇葩方法。那么，降低清晰度到底伤害了谁呢？我们题目就是这样的一个题目。付费用户的权益肯定被伤害，这没什么好说的。我花钱买了4K了，你没给我看，你给我看的比原来模糊了，这个算欺诈消费者。另外一个谎言必须要更多的谎言来弥补。他给我看4K视频，结果比原来1K的还模糊，那这就是个谎言吧。这个谎言其实损害的是整个行业的利益。

什么叫整个行业的利益？这就是视频行业。视频行业从哪开始？从相机，从摄像机，从整个的视频平台，从电视，从电脑，从手机，这都算是视频行业。你看，我最后看视频，我有可能在手机上看，有可能在平板上看，有可能在电视上看。

这都是视频行业。那你一旦撒了这个谎，等于整个行业都受损失。有人说，有这么严重吗？我不就是骗了点钱，给人看了一个低分辨率模糊的视频吗？我还给人加了个滤镜，做了个美颜，做了个锐化，一般人还看不出来，真的有这么严重啊？

咱们这样就要讲一讲，为什么这个事是由影视飓风爆出来的。影视飓风呢，是国内影视知识、影视器材的专业媒体，应该算第一名。他的创始人呢，叫Tim，也算是一个大网红。这个Tim呢，中文名叫潘天虹，算是个富二代。他父亲是圆通速递的总裁潘水苗。

这个小伙子呢，留英学的电影学，回到国内以后呢，就做了这样的一个自媒体，现在也是几百人的公司了。他呢，发现了一个问题是什么？就是你想，这刚才我们讲的什么照相机啊、电视机啊、投影仪啊，你要更新换代啊。更新换代了就找人做评测，找人写软文，找人去拍视频，去吹牛。他们这个影视飓风就专门干这个的。

结果他给人拍的这个视频，比如说，哎，上了一个新相机，我给你拍一下对比视频。这是老相机的，这是新相机的，两个视频左右一对比，说你们看看有区别没有。最后把这视频上到B站上以后，发现没区别，甚至老相机拍的，可能比新相机拍的还好一点。

那这金主爸爸就不干了，说你这不糊弄事呢吗？你拍了视频出去，我新相机没卖掉，这哪成啊？后来人家找原因，找了原因以后说，我是拍出这效果了，这所有的片子在我这看都是对的，新相机这个效果就是比老相机好。但是呢，一旦到了B站上，经过B站的压缩再传播以后，老相机的那个视频的效果，可能就比新相机还好一点。

那这事就没法整了，你跟金主爸爸怎么解释？我收人广告费了，给人拍了这新相机的这个评测，最后发现画质下降了。所以他拍了这样的一个视频，说大家如果再不注意这个问题的话，整个的行业就废了。如果大家都去看这种假4K，那我为什么要去买新相机呢？我为什么要去买新电视呢？4K电视我为什么要买呢？那我去买那个1080P的电视，不就完事了吗？我为什么要去买新的显示器？

为什么要买新手机呢？新的手机讲的是说：“哎，你看我这个手机高通8根2，高通8根3的这个芯片在里头，我可以做AV1编码，AV1解码。”我为什么觉得这个事没有意义呢？你最后喂回来的还是一口屎。如果视频平台在中间去撒谎骗人的话，整个行业就已经失去了升级的动力，大家没有升级的意义了。

你像我拍4K视频到YouTube上，大家还是能看出区别了，4K跟1080P还是不一样。但是你要到国内的，比如B站这些平台上，你上传4K视频，他们根本看不出来，比1080P还糊涂。那么他为什么要去买新的拍摄设备呢？没有任何意义。

我们所有的什么以旧换新，换电视、换手机、换相机，都没有任何意义了。这件事情就是一个被掩盖的谎言，会阻碍整个社会进步的故事。而且呢，这应该仅仅是一个被掩盖的、不能说的、拍了视频马上被下架的一个谎言。在某一个行业里头，如果出现这种谎言的话，那么整个行业就会停滞，甚至倒退。

这就是典型的案例，就是我们看到的糊视频，导致了整个的视频行业，他整个的更新换代全都停下来的一个故事。好，这个故事就跟大家讲到这里。感谢大家收听，请帮忙点赞，点小铃铛，参加Discord讨论群。也欢迎有兴趣、有能力的朋友加入我们的付费频道。再见。

🔲 ⭐

Umami V1 升级到 V2

✇ROYWANG
ROYWANG

前段时间发现，Umami 已经更新到了 V2 版本，遂升级了一下，也遇到不少坑，记录一下。

请注意，升级有风险，请您注意备份已有的数据库以及项目文件，以便升级中遇到错误，进行回退。
另外，此处介绍的为基于 《Umami 自建网站访问量统计系统》做的V1->V2的升级，如您没使用过Umami，请配合本文内容与《Umami 自建网站访问量统计系统》中的内容进行项目部署。

本文中，并无介绍 Node.js 与 yarn 的安装与配置，请参考上面链接中的文章进行安装部署。

项目介绍

项目地址：Umami

Umami 基于Next.js 开发，并且支持 MySQL 或 Postgresql 等数据库存储方式，可以将数据掌握在自己手中。并且 Umami 还提供了非常详细的流量分析可视化的界面，UI 体验以及统计准确度十分不错（此处所讲统计精准度为实际真是访客的访问量，有可能一天只有1-2请做好心理准备。）

官方文档：Umami Docs

升级数据库

本地升级

如果你之前使用过 Umami V1，打算从 V1 升级到 V2，直接执行下面的命令：

cd umami
npx @umami/migrate-v1-v2@latest

上面打开目录，请按照实际情况来修改。

托管平台升级

如果你选择的使用 Vercel 之类的托管平台，以至于没有目录的权限，则需要克隆 V1->V2的升级项目，进行数据库升级。

git clone https://github.com/umami-software/migrate-v1-v2.git
cd migrate-v1-v2
yarn install
yarn build

则需要在文件夹中创建一个 .env 的文件，其内容如下：

DATABASE_URL={connection url}

运行项目以升级数据库结构

yarn start

重新构建

数据库升级成功后，则需要重新构建项目，在此处写明升级方法。

本地构建项目

在构建之前，请备份 .env 文件，备份后需要删除整个 umami 数据库

git clone https://github.com/umami-software/umami.git
cd umami
yarn install

此时需要将备份好的 .env 文件，放回到目录中。

构建项目：

yarn build

构建完成后，可运行项目：

yarn start

配置文件也需要进行更新，原来的 umami.service 已不可使用，请替换为新版：

[Unit]
Description=Umami App
After=network.target

[Service]
Environment=PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/www/server/nodejs/node-v16.14.2-linux-x64/bin/
ExecStart=/www/server/nodejs/node-v16.14.2-linux-x64/bin/yarn start
WorkingDirectory=/www/wwwroot/umami
Restart=always
RestartSec=10
Type=simple
User=root
Group=root

[Install]
WantedBy=multi-user.target

此时保存即可，运行：

# 更新配置
systemctl daemon-reload
# 启动服务
systemctl start umami
# 设置开机启动
systemctl enable umami

详细的管理命令如下：

# 启动服务
systemctl start umami
# 设置开机启动
systemctl enable umami
# 停止服务
systemctl stop umami
# 重启服务
systemctl restart umami
# 查看状态
systemctl status umami
# 更新配置
systemctl daemon-reload

使用 Vercel 构建 Umami V2

有关 Vercel 构建 Umami V2的方法，与构建 V1 并无区别，可参考我写的这篇文章：

《Vercel 云服务构建 Umami》

其他

之前的文章介绍过使用 CDN 加速 Umami 的脚本，Umami升级到V2后，脚本内容已经更新，需要您更新托管到 CDN 的静态文件。

下载文件，然后上传到服务器即可。

升级后，网站上的配置链接不必进行更改。

如在安装或构建过程中遇到错误，请检查使用的 Node.js 版本与 yarn 版本是否不符合要求，或者过于新。官方要求 Node.js 版本 14.3 或更高。

《Umami V1 升级到 V2》

🔲 ⭐

升级到 MovableType R5404

✇SEO 网站优化及网站推广
David Yin

刚刚升级了 MovableType，这个曾经非常著名的系统。

升级过程简单，也没有什么可以赘述的。而最新的版本，其更新内容如下：

New and Improved features


Optimization of internal processing

Some internal processing has been optimized. Page rebuilds are now about 10% faster. For the detail, see New features and improvement for Movable Type 8

Search and Replace

Enabled to add revision memo when replacing on Search and Replace page. (MTC-27696)
Fixed the order of results of search with sort_by date-based key in mt-search.cgi, mt-cdsearch.cgi or Data API (MTC-28689)

Data API

Added Data API version 6. The default value of the Limit parameter of Stats is changed to 50, previously 10 (MTC-28721)
Improved error handling in normal operations internal DATA API (MTC-28707)

详细的更新log 看这里。

❌