起因

最近开始接触 iOS / Swift 开发，但是 XCode 是众所周知的难用。作为一个习惯了 VSCode 生态的开发者，我决定试试能不能在 VSCode 里写 iOS 项目。

然后第一步就困住了：怎么配环境呢？

VSCode 装上 Swift 官方插件后，发现 LSP 居然不工作，只有 VSCode 自带的高亮。一查才发现：官方 Swift 插件只支持 SPM 项目（即有 Package.swift 的项目），而我手上的项目是 .xcodeproj + CocoaPods 的传统结构，这就导致 LSP 无法获取编译参数，自然也就没有智能功能了。

折腾了一圈，终于配出了一个能用的环境，记录一下过程，希望能帮到同样想逃离 Xcode 的人。

视频链接

【正片】周鸿祎×罗永浩！近四小时高密度输出！周鸿祎深度谈 AI

核心观点概览

AI 并非简单工具升级，而是引领社会变革的强大力量。语言模型构成构建世界认知的基础，智能体前景广阔。AI 发展同时面临挑战与伦理难题，需务实应对并构建健康生态。

1. 先有文本模型，才能搞世界模型

• 语言是认知世界的基石：语言是人类沟通与知识传承的核心，也是 AI 理解世界的基础。即使失去视觉与听觉，海伦·凯勒仍通过语言构建完整世界认知。
• 语言模型是世界模型起点：AI 通过语言模型掌握人类知识、逻辑推理与世界描绘，比单纯感知信息更根本。一旦语言智能突破，图像、视频等物理与空间智能将迅速跟进。
• “世界模型”误区：过早追求世界模型而忽视语言，属于本末倒置。语言才是打开智能大门的金钥匙。

Intro

对比 zaf/resample 和 zeozeozeo/gomplerate 两个库的性能表现。

前者基于 CGO 和 libsoxr C 库，后者为纯 Go 实现。

测试结果

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

> CGO_ENABLED=1 go test -tags soxr -bench=. -benchmem
goos: darwin
goarch: arm64
pkg: github.com/luoling8192/benchmark
cpu: Apple M4 Pro
BenchmarkResample_48k_to_16k_mono/purego/frames=240-12            592992              1911 ns/op        1004.65 MB/s        6768 B/op         18 allocs/op
BenchmarkResample_48k_to_16k_mono/purego/frames=480-12            294157              3782 ns/op        1015.24 MB/s       13552 B/op         20 allocs/op
BenchmarkResample_48k_to_16k_mono/purego/frames=960-12            152620              8024 ns/op         957.14 MB/s       36080 B/op         23 allocs/op
BenchmarkResample_48k_to_16k_mono/purego/frames=1920-12            72862             16160 ns/op         950.49 MB/s       80369 B/op         26 allocs/op
BenchmarkResample_48k_to_16k_mono/purego/frames=48000-12            2707            438796 ns/op         875.12 MB/s     2574854 B/op         46 allocs/op
BenchmarkResample_48k_to_16k_mono/soxr/frames=240-12               93116             12589 ns/op         152.51 MB/s        3352 B/op          5 allocs/op
BenchmarkResample_48k_to_16k_mono/soxr/frames=480-12               90708             12963 ns/op         296.22 MB/s        6680 B/op          5 allocs/op
BenchmarkResample_48k_to_16k_mono/soxr/frames=960-12               76482             13896 ns/op         552.69 MB/s       13592 B/op          5 allocs/op
BenchmarkResample_48k_to_16k_mono/soxr/frames=1920-12              56086             21418 ns/op         717.15 MB/s       27160 B/op          6 allocs/op
BenchmarkResample_48k_to_16k_mono/soxr/frames=48000-12              3708            295917 ns/op        1297.66 MB/s      650306 B/op          6 allocs/op
PASS
ok      github.com/luoling8192/benchmark        12.594s

分析

小批量数据（240-1920 frames）

• purego 完胜: 1.9-16 μs/op，吞吐量 950-1004 MB/s

• soxr 较慢: 12-21 μs/op，吞吐量 152-717 MB/s

• 原因: CGO 调用开销 + C 库初始化成本在小数据量时占主导

大批量数据（48000 frames，1秒音频）

• soxr 反超: 295 μs/op，1297 MB/s

• purego: 438 μs/op，875 MB/s

• 提升: ~48% 性能提升，这才是 C 库该有的表现

内存分配对比

1
2
3
4
5
6
7

小批量 (240 frames):
  purego: 6768 B/op, 18 allocs/op
  soxr:   3352 B/op,  5 allocs/op  ← 更少分配

大批量 (48000 frames):
  purego: 2.57 MB/op, 46 allocs/op
  soxr:   0.65 MB/op,  6 allocs/op  ← 内存效率高 4 倍

结论

对于语音通话场景，可以选择纯 Go 实现，关闭 CGO 之后工程更易维护且性能不会太差。

可以使用 Tag 来控制切换使用 CGO 版本还是 Pure Go 版本。

git-filter-repo

安装 git-filter-repo

1

brew install git-filter-repo

克隆一个新的仓库，之后可以先查看 .git 文件夹的大小：

1
2

> du -sh .git
512M    .git

可以通过下面的命令来查看都有哪些 blobs

1

git filter-repo --analyze

发现大多数都是二进制文件

1
2
3
4
5
6
7
8
9
10
11

> head .git/filter-repo/analysis/path-all-sizes.txt 
=== All paths by reverse accumulated size ===
Format: unpacked size, packed size, date deleted, path name
   470130748  178598150 2025-11-10 platform
   243521416  113247661 2025-10-23 console
    46809010   21775586 2025-08-20 c_app
    54705026   20429606 2025-06-13 cmd/realtime/__debug_bin913888059
    42808594   15271725 2025-07-04 hack/custom-gcl
    54721890   10697777 2025-06-13 cmd/realtime/__debug_bin2869633227
    54718178   10581905 2025-06-13 cmd/realtime/__debug_bin2562572020
    54705026    7964676 2025-06-13 cmd/realtime/__debug_bin1245928177

那我们使用下面的命令来清理大于 10MB 的 blobs 文件

1

git filter-repo --strip-blobs-bigger-than 10M

清理完成之后，运行下面的命令来移除掉未引用的对象：

1

git gc --prune=now --aggressive

再次运行 analyze 命令查看

1
2
3
4
5
6
7
8
9
10
11
12

> git filter-repo --analyze
> head .git/filter-repo/analysis/path-all-sizes.txt
=== All paths by reverse accumulated size ===
Format: unpacked size, packed size, date deleted, path name
      632173     625888 <present>  misc/test.png
     6723898     181368 <present>  api/generated/platform/v1/character.pb.go
      186702     166919 <present>  misc/test.wav
    21519778     116651 <present>  ent/mutation.go
     3185297      81278 <present>  go.sum
     1850619      53671 <present>  api/generated/realtime/v1/realtime.pb.go
    14689422      38565 <present>  api/generated/v1.swagger.json
      744797      36489 <present>  api/generated/console/v1/task.pb.go

发现刚刚显示的二进制文件已经没有了

再次查看 .git 大小

1
2

> du -sh .git
6.6M    .git

这个时候推送到远端，应该使用 --force-with-lease 防止覆盖新的提交

1

git push --force-with-lease --all

最后要注意的是，所有的人应该拉取新的仓库，否则可能会把之前的记录再次推送上来导致清理无效。

问题描述

Apple TV 连接 HomePod Mini 作为默认音频输出后，使用 Moonlight 进行游戏串流时出现严重丢包，表现为画面周期性卡顿（micro-stuttering）、延迟飙升，体验极差。

断开 HomePod 连接后问题立即消失。

根因分析：AWDL 信道跳变

罪魁祸首是 AWDL（Apple Wireless Direct Link）——Apple 的私有无线点对点协议，用于支持 AirDrop、AirPlay、Sidecar 等设备间直连功能。

AWDL 是什么

AWDL 是 Apple 从 iOS 7 / macOS Yosemite 开始引入的无线直连技术，允许 Apple 设备不经过路由器，直接通过 Wi-Fi 射频进行点对点通信。它后来被 Wi-Fi 联盟采纳，成为 NAN（Neighbor Awareness Networking）标准的基础。

每个 AWDL 节点会广播一系列 Availability Windows（AW），表示自己可以与其他 AWDL 节点通信的时间窗口。节点间通过选举产生一个 master 节点来同步这些时间窗口。

为什么会导致丢包

AWDL 只使用三个固定信道：

当 Apple TV 通过 AirPlay 连接 HomePod Mini 时，AWDL 被激活以维持这条点对点音频链路。关键问题在于：如果你的 Wi-Fi 网络不在 AWDL 使用的信道上，Wi-Fi 射频模块就必须在两个信道之间反复跳变——先切到 AWDL 信道处理 AirPlay 数据，再切回基础设施信道处理正常网络流量。

这种信道跳变会造成：

• 周期性延迟尖峰：Bonjour 发现过程每秒产生约 50-100ms 的延迟尖峰
• 丢包：射频模块在 AWDL 信道上工作时，正常 Wi-Fi 信道上的数据包无法被接收
• 节律性卡顿：因为跳变是周期性的，表现为非常有规律的 stuttering

正常情况下 ping 延迟在 2-10ms，AWDL 活跃时可飙升至 200ms。对于 Moonlight 这种对延迟极度敏感的游戏串流应用，这是灾难性的。

为什么断开 HomePod 就好了

断开 HomePod 音频连接后，Apple TV 不再需要维持 AirPlay 点对点链路，AWDL 回到低功耗的被动监听状态，信道跳变频率大幅降低，丢包问题随之消失。

但注意：即使没有连接 HomePod，AWDL 也不会完全安静。只要隔空投送开启且附近存在 Apple 设备，AWDL 会周期性进行 Bonjour 发现扫描，每次扫描都会短暂锁定 Wi-Fi 射频并切换信道。虽然频率远低于活跃 AirPlay 连接，但对延迟敏感的串流应用仍然可能感知到偶发的延迟尖峰。关闭隔空投送可以抑制这部分扫描。

解决方法

方法一：断开 HomePod 连接（最简单）

在 Apple TV 设置中将音频输出切回 Apple TV 内置扬声器或改用有线/蓝牙音频设备，避免 AirPlay 音频链路触发 AWDL 高频信道跳变。

方法二：将 Wi-Fi 信道调整为 AWDL 信道（推荐）

在路由器设置中，将 5 GHz Wi-Fi 信道手动设置为 Ch 44（亚太/欧洲）或 Ch 149（美国）。当 Wi-Fi 基础设施信道与 AWDL 信道一致时，射频模块无需跳变，延迟尖峰消失。

方法三：关闭隔空投送

关闭隔空投送（AirDrop）可以阻止 AWDL 的周期性 Bonjour 发现扫描，减少无 AirPlay 连接时的偶发延迟尖峰。在 Apple TV 上进入「设置 > 隔空投送与接力」关闭即可。

方法四：使用有线连接（最终方案）

Apple TV 使用以太网连接是最稳定的方案。有线连接完全绕过 Wi-Fi 射频争用问题，串流数据走有线网络，AWDL 的周期性扫描和 AirPlay 音频链路只影响无线射频，两者互不干扰。HomePod 音频也能正常使用。

实测这是唯一能彻底解决问题的方案——即使调整了信道，Bonjour 周期性扫描仍可能带来偶发抖动，有线连接则完全不受影响。

参考资料

• Fixes for Low-Latency Desktop Streaming stuttering on macOS
• AppleTV, AirPlay and AWDL protocol with Wi-Fi
• The impact of AWDL on Mac Wi-Fi performances
• Open Wireless Link - AWDL Wiki
• AWDL Symphonizer - Fix macOS Wi-Fi stuttering

背景

已经在软路由上配置好了 tailscale 之后，发现虽然其他设备可以连接到软路由，但是不能科学上网。

解决方法

进入 shellcrash 设置后，选择【7 内核进阶设置】-> 【3 配置公网及局域网防火墙】 -> 【3 自定义透明路由ipv4网段】-> 输入 100.0.0.0/8，保存并重启内核即可。

问题描述

可以访问互联网，Chrome 浏览器访问同网段的其他设备提示 ERR_ADDRESS_UNREACHABLE

Safari可以访问，Chrome 浏览器不能访问。

尝试过多种方式，如重置本地网络，刷新DNS缓存，切换DNS服务器，重置Chrome设置等，均无效。

通过 Wireshark 抓包发现 Chrome 访问内网设备直接都没流量出去。

解决方法

最后发现：需要在设置中打开本地网络访问权限。

文章来源

转载自：Mac 电脑访问网页提示 ERR_ADDRESS_UNREACHABLE

解决方法

开启 nesting 功能

参考资料

systemd “Failed to set up mount namespacing” · Issue #4127 · lxc/lxc

起因

经常用 macOS 的用户都知道，鼠标的滚动方向和触控板的滚动方向是一致的，即为自然滚动，但是在 Windows 上，没有一个很好的方法可以快速调节滚动方向到自然滚动。

网上有很多教程教如何使用注册表来修改鼠标的滚动方向，本文不再赘述。

方法

可以在 constant.ts 中直接 import package.json 并使用其中的版本号：

1
2
3
4

import pkg from '../package.json';

const version = pkg.version;
console.log(version); // 1.0.0