首先申明： 本文不是广告，也不推荐任何保险产品 。

我之前一直不理解保险，最近借助一些资料，终于想明白了各种保险的价值，给大家分享一下。

保险其实分很多种，我们需要分开理解它的用途。

一、意外险

意外险是杠杆最高的保险。每年大概几百块钱，就可以保上百万的保额。因为对于大部分人来说，这个事情发生的概率极低，所以它的杠杆很高。

意外险的价值是给家庭或者父母留下一笔财富。特别适合家里面负责挣钱的那个顶梁柱买，这样可以应对极端概率情况下的风险。

很多人会想：这么低的概率，有必要买吗？有可能一辈子都遇不到意外。

我们在考虑这种保险的时候，要有 “平行宇宙”思维。即：我们要假设这个世界是量子态的，同时有许多平行宇宙，意外险是为众多平行宇宙中的某一个 “我” 的意外买单。这样，那一个平行宇宙里面的倒霉的 “我”，被另外平行宇宙中的 “我” 的保费接济，获得了极大的补偿。

我们不知道我们身处在哪个平行宇宙。所以意外险保证了我们在每个平行宇宙过得都不算太差，最倒霉的那个 “我”，也用保险给家庭留了一大笔钱。

二、医疗险

医疗险大多数报销门诊或者住院时候的大额费用。一般这种保险都有起付金额（比如超过 1 万部分）。

这种医疗险的费用也很低，一年也是几百块钱就可以买到。这种保险其实也是杠杆率很高的保险，因为大部分年轻人不太会超过起付金额。

医疗险和意外险类似，也是保障极端情况，比如如果一个突发疾病住院要花 10 来万，这个保险就可以报销大部分，让家庭不至于因病返贫。

三、高端医疗险

高端医疗险一般一年费用得好几千，是普通医疗险的 10 倍。大概率高端医疗险是很难从期望上 “回本” 的，而且很多疑难杂症，可能公立的三甲医院医生更有临床经验（因为他们看的病例更多）。

购买高端医疗险更多可以看成是一种 “消费”。因为你得任何小病都可以享受非常好的看病体验，不用担心看个感冒花几千块钱（是的，和睦家看个感冒几千块钱很正常）。

四、分红险

分红险在我看来已经脱离了保险原本的意义，但是最近我稍微理解了一点它的价值。

分红险通常需要购买者每年交上万块钱，连续交 20 年左右，之后开始累积复利，最后在几十年后，可以提取出来一笔财富。在现在低利率时代，它能保证的年化收益大概有 2.5% 左右（以后如果利率下行应该收益会更低一点）。

我开始很不喜欢分红险，因为首先它的收益率并不高。不管是股票，债券，还是黄金，如果你拉一下 30 年收益率的话，大多数都远远超过 2.5% 。另外，这笔几十万的保费，其实是丧失了几十年的流动性，如果你要强行赎回，就会损失巨大。我认为现金流对家庭来说还是很重要的，所以我很不喜欢这类保险。

大部分销售推销的香港保险也属于这类。

哦，不得不提，这类保险也是对销售来说提成最高的产品。这也是我不喜欢它的原因。因为这就相当于你的本金一开始就打了一个 9 折，对于一个打折的本金，它的复利增长就更难。

那我现在为什么稍微理解了它呢？因为我发现大部分人只会把钱存定期。对于一个定期存款来说，换成这种保险，稍微能够提升一点点长期收益率，同时帮助这些人能够 “锁定” 财富，如果希望这个钱用于养老，它被锁定就不至于被各种意外用掉。

但是我个人还是宁愿持有股票或债券。

另外，给孩子买这个保险的家长可能要想清楚，这个保单什么时候兑现？如果一直不兑现，理论上可能是给 “孙子” 买的，那么做好保单两代人的传承也是一个问题。因为如果 10 岁给孩子买，那么要 60 年之后可能才会兑现保单价值。到时候大概率自己已经不在了，孩子已经 70 岁了，保单传承不好就相当于捐给保险公司了。

五、终身寿险

高额的终身寿险其实相对于把意外险和分红险做了一个组合。拿分红险的收益来 cover 意外险的保费。美其名曰：如果意外发生可以保多少，最后你还能拿回全部本金，还附加一些特别红利（不保证兑现）。

殊不知羊毛出在羊身上，本金每年的部分利息就其实是意外险的成本。只是换了一个说法和组合。

我是很不喜欢这种类似雪球的复合结构，因为你搞不明白年化收益率，也搞不明白你的意外险部分的杠杆率。

七、车险

车险里面的车损险是杠杆率极低的产品。拿我的特斯拉来说，一年保费要 5000 多，但是我大部分时候在城市里面开，就算有小磕碰，修车也不会花到这么多。

车险里面杠杆最高的是三者险，大概 600 块钱左右就可以保 200-300 万的保额。这样万一撞到人或者豪车，都可以 cover 全部费用。

我已经连续很多年只买交强险和三者险。这也让我驾车的时候更小心，自己不撞别人就不需要车损险，如果别人撞到自己，可以走别人的保险。

八、小结

• 意外险和医疗险可以保证极端情况发生后的体验，杠杆很高，费用相对低（一年几百块钱）
• 高端医疗险类似消费，提升普通看病体验，一年几千。
• 分红险年化收益不如很多股票和债券等产品，但是比定期强。另外牺牲了现金流，但同时保证这笔钱不会被挪用。因为利润高，销售都喜欢卖这个产品。
• 终身寿险是意外险和分红险的组合。
• 车险里面三者险杠杆最高，车损险性价比低。

以上。本文仅表达个人观点，不构成任何购买建议。

真相有时候不重要，举几个例子。

第一个例子是身边一个朋友的故事。一天早上，从来不做饭的妻子心血来潮，给他做了一份早餐，但是因为是第一次做，手艺不太娴熟。这个时候，妻子问他味道怎么样？他随口就说：感觉一般。妻子的脸色瞬间就阴下去了，说：那我以后再也不做饭了。对于妻子来说，早餐好不好吃的真相不重要，鼓励和认可才是重要的。丈夫说了实话，但是却伤了妻子的心。

去年农夫山泉被全民网暴的时候，我发文章说农夫山泉的瓶盖和日本国旗没关系。结果一堆人在评论区谩骂我。对于网暴的人来说，真相不重要，情绪和宣泄的重要性大于真相。对于这些谩骂的人来说，我忽略了讲真话的时机，所以被骂。

在今年的脱口秀节目上，一个脱口秀演员提到自己的爸妈本来打算把自己打掉的，老罗也提到他也有同样的家庭情况，他花了很多年很多时间才对这个事情“放下”。对于老罗来说，“自己出身下来不是被需要的”这个真相不重要，重要的是自己的人生意义。即便是事实，如果会伤害孩子，父母本来可以不说，真相不重要。

我们曾经有一个实习生，偷偷利用公司的9点后加班可以打车福利，下班后去健身房，然后等到9点后再打车回家。我们后来给他说，我们实习岗位取消了，让他离开了公司。对于我们来说，告诉他离开的真相不重要，对于不合适的人，让他快速地离开不会起任何冲突。对于我们来说，事情顺利地执行比说出真相重要。

我是一个业余编程老师，编程这件事情很难，所以孩子第一次接触编程容易会发怵。这个时候，我会设置一些很简单的题目，但是告诉他这个题目很难，然后等他做出来，我会惊讶地说：哇，你真的很有天赋！对于孩子来说，真相不重要，学习的兴趣和信心最重要。

对于美国两党各自拥护的媒体，真相也不重要。如果发现事情有利于他们的政治宣传，他们就大力宣传。如果发现事情不利于他们的政党，他们就会有意淡化。在美国，媒体的中立客观在政治面前不重要，政治更重要。

邓小平很早就明白真相不重要。每次被打倒他都默默承受，尽力照顾好自己的家人，不争辩不气馁。因为他知道，在那个时候只要是他说的，就都是错的，真相不重要。在后来，邓小平坚决保护毛主席，保护国家稳定，因为他知道：稳定大于一切。只要政局稳定，一切问题都可以慢慢解决。而如果为了真相导致政局混乱，那将天下大乱。

有些时候，真相因为不太容易被人接受，甚至会变成秘密，比如大家的工资。试想一下，如果每个人的工资是公开的，那么就会有大量的人向 HR 投诉自己的薪资为什么不如某某某。因为人们总是容易高看自己，低看别人。所以，薪资的真相变得不重要，大家相互之间不知道薪资变得很重要。

那真相很多时候不重要，我们是不是就不需要真相了？不是的。大部分时候，真相都是重要的。大部分时候，我们也需要讲真话，追求真相。只是我们需要明白，这个世界在运转过程中，真相的权重不一定是最大的。当真相被掩盖的时候，我们可能需要接受这样的现实。当我们决策的时候，有时候需要相对真相，给其他因素更高的权重。

最后，我想引用最近看到的一篇《南方周末》的报道 佛学与官场，一个主持的官场往事。在文章中，释传真（时任南京市佛教协会副会长）说：

我常常跟来聊天的官员说，做官啊，第一有文化没文化要学会听话；
第二，得过且过太阳出来暖和；
第三，有一些矛盾就要睁一只眼闭一只眼。

你看，一位佛教高僧给官员的经验分享，每一点都在说：有比真相更重要的事情。

以上。最后再强调一遍：我不是教大家骗人，我是在强调给真相赋予合适的决策权重。

AirDrop 让使用者可以在各种不同类似的苹果设备上高效、无损的传输数据，它一直是苹果生态的专属且核心功能。但，这种情况现在出现了“奇怪”的变化。几天前，谷歌宣布在 Pixel 10 中，在没有苹果的参与下，为 Quick Share 提供了 AirDrop 的兼容机制，实现了安卓手机与苹果手机基于 AirDrop 的无线互通。

一、事件传递

事件传递相关的两个方法

// 哪个视图响应事件返回哪个  
-(UIView *)hitTest:(CGPoint)point withEvent:(UIEvent *)event;     
// 点击位置是否在当前视图范围  
-(BOOL)pointInside(CGPoint)point withEvent:(UIEvent *)event; 

如图，View A中包含View B1、View B2,View B2中包含View C1，View C2既包含View C1的一部分，又包含View B2的一部分，View C1中包含View D。当点击View C2的空白区域时，系统如何找到事件响应者为View C2？

（1）事件传递流程

当用户点击屏幕的某个位置，该事件会被传递给UIApplication，UIApplication又传递给当前的UIWindow,UIWindow会通过hitTest:WithEvent:方法返回响应的视图。hitTest:WithEvent:方法内部通过pointInside:withEvent:方法判断点击point是否在当前UIWindow范围内，如果在，则会遍历其中的所有子视图SubViews来查找最终响应此事件的视图，遍历方式为倒序遍历，即最后添加到UIWindow的视图最优先被遍历到，依次遍历，可以看作是递归调用。每个UIView中又都会调用其对应hitTest:WithEvent:方法，最终返回响应视图hit,如果hit有值，则hit视图就作为该事件的响应视图被返回，如果hit没有值，但在当前UIWindow范围内，则当前UIWindow作为事件的响应视图。

（2）hitTest:WithEvent:系统内部实现

首先在hitTest:WithEvent:方法内部先判断当前视图的hidden属性、是否可交互、透明度是否大于0.01。如果该视图不同时满足上述3个条件，则返回nil，当前视图不作为事件的响应视图，当前视图的父视图继续遍历其他的子视图；如果该视图没有隐藏、用户可交互、透明度大于0.01，则会通过pointInside:WithEvent:方法判断点击的点是否在当前视图范围内，如果不在，则同样返回nil,当前视图仍不作为事件的响应者；如果在，则会通过倒序遍历当前视图的子视图，调用其子视图对应的hitTest:WithEvent:方法，如果某个视图返回了事件响应视图，则该返回的视图被作为事件的响应者，反之则继续遍历判断。如果遍历完后没有任何视图响应此事件，因为此事件点击的范围在当前视图范围内，则将当前视图作为事件响应者返回。

二、视图事件响应

上述讲述了视图事件的传递流程，当视图事件传递后，最终事件由谁来响应呢，这就涉及视图的响应链、响应链的机制和流程。 如图，页面存在一个UILabel、一个UITextField、一个UIButton，实线箭头表示下一个响应者。

视图事件响应链相关的方法

- (void)touchesBegan:(NSSet<UITouch *> *)touches withEvent:(UIEvent *)event
- (void)touchesMoved:(NSSet<UITouch *> *)touches withEvent:(UIEvent *)event
- (void)touchesEnded:(NSSet<UITouch *> *)touches withEvent:(UIEvent *)event

例如，当点击View C2的空白处时，事件由谁来响应呢？首先由View C2接收事件，如果它不处理，就会把事件传递给View B2,如果View B2还不响应这个事件，View B2会通过响应链将事件传递给它的父视图View A,如果还不响应，则会沿着响应链一直向上传递，直到传递到UIApplicationDelegate仍然不对事件进行处理，则会忽略此事件。

自 iOS 17 起，SwiftUI 引入了 全新的 Observation 模型。

它用三个核心工具彻底重塑了数据管理方式：

• @Observable —— 定义可观察的状态模型

• @State —— 持有模型实例，等价于旧时代的 @StateObject

• @Bindable —— 在视图中实现对 Observable 模型的双向绑定

如果你还在用 ObservableObject、@Published、@StateObject、@ObservedObject、@EnvironmentObject，是时候升级了：新范式更简单、更 Swift、更高性能。

本文将系统梳理 SwiftUI 最新的数据管理体系。

---

🧱 一、旧数据体系的问题

iOS 16 及以前，我们管理状态基本依赖：

• ObservableObject

• @Published

• @StateObject

• @ObservedObject

• @EnvironmentObject

这些机制的问题：

• 装饰器太多，容易混乱

• 生命周期容易搞错（尤其是 @StateObject vs @ObservedObject）

• @Published 对属性执行全局广播，性能不够优雅

• 环境写法不够类型安全

新模型的目标：让 SwiftUI 更简单、更自动、更智能。

---

🚀 二、@Observable：新时代核心

新系统中的任何可观察模型，只要声明：

@Observable
class UserModel {
    var name = "HanQiu"
    var age = 23
}

不再需要：

• ObservableObject

• @Published

• 手动发布变更

所有存储属性都是可观察的，SwiftUI 会精确追踪变化来源。

---

🧩 三、@State取代@StateObject

在旧时代，创建页面级别持久的模型需要：

@StateObject var vm = UserModel()

在新系统中：

@State var vm = UserModel()

是的， @State 自动完成以前 @StateObject 的作用：

• 保持引用类型实例生命周期

• 在视图重建中保持稳定

• 触发视图刷新

只要你的模型是 @Observable 的，就可以用 @State 持有。

---

🧠 四、那@ObservedObject呢？—— 不需要了

旧写法（子视图）：

struct ProfileView: View {
    @ObservedObject var vm: UserModel
}

新写法：

struct ProfileView: View {
    var vm: UserModel
}

SwiftUI 会自动观察视图中“被使用的属性”。

你不需要告诉它“这个对象可观察”，它本身就知道（因为模型是 @Observable）。

---

🌿 五、环境注入方式的升级

旧写法：

@EnvironmentObject var settings: SettingsModel

新写法更强、更明确：

注入

struct AppRoot: View {
    @State var settings = SettingsModel()

    var body: some View {
        MainView()
            .environment(settings)
    }
}

获取

@Environment(SettingsModel.self) var settings

减少误用，也更符合 Swift 语言本身的表达。

---

⭐ 六、重点：@Bindable的出现解决了什么？

@Observable 模型虽然自动可观察，但 UI 控件（如 TextField）需要 双向绑定：

TextField("Name", text: $vm.name)

新模型中，属性只是普通 stored property，不是 Published，不具备 Binding 能力。

于是 Swift 引入：

✔@Bindable

为 View 提供 绑定视角的模型访问。

---

🧲 七、@Bindable的标准用法

模型

@Observable
class UserModel {
    var name = ""
    var age = 18
}

视图（可编辑 UI）

struct EditUserView: View {
    @Bindable var user: UserModel

    var body: some View {
        Form {
            TextField("Name", text: $user.name)
            Stepper("Age: \(user.age)", value: $user.age)
        }
    }
}

只需标记 @Bindable，模型属性即可自动得到 $binding。

---

🧩 八、为什么不是所有时候都用@Bindable？

是否需要取决于：

情况	是否需要 @Bindable
仅用于展示，不会修改模型	❌ No
需要用 TextField / Toggle / Stepper 修改模型	✔ Yes
子视图要修改父模型	✔ Yes
完全只读视图	❌ No

越“表单”风格的页面，越需要 @Bindable。

---

🚦 九、@Bindable的局部绑定写法（推荐技巧）

你也可以只在 body 内使用 Bindable：

var body: some View {
    @Bindable var b = user   // 局部绑定

    VStack {
        TextField("Name", text: $b.name)
        Stepper("Age: \(b.age)", value: $b.age)
    }
}

不会污染结构体属性定义，适合仅局部可编辑的 UI。

---

🧭 十、三者关系总结（最重要）

@Observable   —— 使模型可观察
@State        —— 在 View 中持有模型（生命周期 = 旧 @StateObject）
@Bindable     —— 提供绑定能力，允许 UI 修改模型

一个“完整数据流”的表达式：

@Observable 定义状态 → @State 持有 → @Bindable 编辑 → SwiftUI 自动刷新

---

🧪 十一、完整示例：新 Paradigm 最佳实践

@Observable
class ProfileModel {
    var name = "HanQiu"
    var level = 1
}

struct ProfileView: View {
    @State var profile = ProfileModel()

    var body: some View {
        VStack {
            Text("Name: \(profile.name)")
            Text("Level: \(profile.level)")

            EditSection(profile: profile)
        }
    }
}

struct EditSection: View {
    @Bindable var profile: ProfileModel

    var body: some View {
        VStack {
            TextField("Name", text: $profile.name)
            Stepper("Level: \(profile.level)", value: $profile.level)
        }
        .padding()
    }
}

无需 @Published，不用 @StateObject，不需要 @ObservedObject。

SwiftUI 的数据管理彻底简化。

---

🧾 十二、迁移指南（旧 → 新）

旧 API	新 API
ObservableObject	@Observable
@Published	不需要
@StateObject	@State
@ObservedObject	删除，直接传模型
@EnvironmentObject	.environment(model) + @Environment(Model.self)
双向绑定属性	使用 @Bindable

---

🎉 总结

SwiftUI 从 iOS17 开始进入 Observation 时代：

• @Observable → 自动观察

• @State → 管理模型生命周期

• @Bindable → 构建表单/编辑 UI 的关键

• 更少的装饰器

• 更精准的性能优化

• 更符合 Swift 语言设计哲学

如果你写 SwiftUI，这套新范式未来几年都会是主流。

---