本次草稿依据提交记录，未逐行核对实现。依据提交：（2026-10-31，feat(ios): 接入系统原生 TabBar 与跟手动效，优化相册预览与灵感卡片交互）。提交信息只给出方向，未给出具体组件名、手势参数或实现文件，本文只按提交信息展开，不编造具体组件名与实现细节。
为什么换到系统原生 TabBar
跨平台 TabBar 的优点是统一：同一套代码、同一套样式，三端长得一样、行为一样。但 TabBar 是用户每天触摸几十次的东西，它的手感属于系统级体验。iOS 用户对它的期待来自整个系统：点击切换的响应、转场、毛玻璃质感、底部安全区留白、与导航栏的配合。这些期待是肌肉记忆，差一点就能感觉出来。
换原生，首先换的是手势跟手程度。跨平台切换往往是触发式的：点下去，触发切换事件，再播放一段写好的动画，手指抬起来了动画才开始。原生切换更像手指直接推着界面走：按下、滑动、松开，界面跟着手指进度走，松开时机与速度决定完成还是回弹。这种跟手感很难用固定时长动画模拟，因为它不是一段动画，而是一段由手势实时驱动的过渡。
其次是转场与导航的一致性。TabBar 与导航栈、页面转场、模态弹出连在一起，用系统原生 TabBar，切换与系统导航转场更容易保持一致，不会出现“Tab 切过去了，导航栏动画还停在上一页”的割裂感。对用户来说，一致性就是“这个应用像 iOS 应用”。
毛玻璃与安全区也值得交给系统。iOS TabBar 的半透明毛玻璃、不同机型的底部留白，系统原生组件是跟着系统走的；跨平台实现要自己模拟模糊半径、亮度变化与各机型适配，成本高且容易在不同系统版本上表现不一。
代价同样直接：iOS 从此有了一条自己的分支，样式、行为、边界情况要单独验证与维护，Android 与 Web 仍是跨平台 TabBar，三端要保持“足够一致”而非“完全相同”。对 TabBar 这种高频触点，这笔维护成本通常是值得的。
跟手动效：手势进度驱动动画
“跟手动效”不是“滑动切换”。触发式切换是离散的：手势达到阈值才触发，之后播放动画，手势与动画是两个阶段。跟手动效是连续的：手指移动 10%，界面就移动 10%；手指停住，界面停住；手指往回走，界面往回走。动画没有自己的时间线，它的时间线就是手指的时间线。只有松开那一刻才需决策：按当前进度与松开速度，决定完成切换还是回弹，再补一段收尾动画送到目标或弹回起点。
实现关键有三点：手势进度要能实时连续读出，而非只在结束时给结果；动画进度要能被手势直接驱动，而非只能播放或停止；松开时的决策要果断，不能让界面悬停在两个页面之间。边界回弹也一样：滑到边界时给阻尼，越近边界、手指带来的位移越小，像拉一根有弹性的绳子，松开后再弹回边界内。阻尼曲线调得好不好，直接决定“到头了”的感觉是柔和还是生硬。
触发式给人的感觉是“我发命令，应用执行”；跟手给人的感觉是“我直接在推界面”。前者是遥控器，后者是直接上手。对相册与卡片这类高频手势，直接上手几乎是必需的。
相册预览与灵感卡片
相册预览是最典型的跟手场景：左右滑动看照片，手指推着照片走，松开后决定翻到下一张还是回到当前这张。滑动返回同样应跟手：向下拖，照片跟着下移、缩小，背景渐暗或渐透明；拖够远松开就回列表，拖不够就弹回全屏。照片缩放、透明度、背景变化都应由手势进度驱动，而非分段触发。
缩放最容易做坏：双击放大、双指缩放、缩放后拖动查看之间有优先级与冲突。双指缩放时单指滑动应被抑制；缩放到边界时拖动应有阻尼；缩到 1:1 以下松开应弹回。把这条手势链理顺，比实现缩放本身更花时间。提交信息所说的“优化相册预览”，很可能指的就是这类细节：不是加新功能，而是把已有手势理顺。
灵感卡片与相册相似又不同。相似的是滑动、切换、返回的手势逻辑相通；不同的是卡片是复合视图，带有标题、文字、标签与操作按钮。卡片上的按钮与卡片整体手势会有冲突：点按钮应是点按钮，滑卡片应是滑卡片。常见处理是按起始位置与移动方向区分：起始在按钮上且无明显滑动是点击，一旦有明显滑动趋势就交给卡片手势。阈值太灵敏会误触按钮，太迟钝则点按钮显拖沓。卡片横向切换时，同样应由手势进度驱动，下一张从边缘跟进来，当前张逐渐移出。
小结
接入系统原生 TabBar，换来的不只是一个更像 iOS 的底部栏，而是一整套系统级手感：跟手的手势、一致的转场、自然的毛玻璃与安全区。跟手动效的核心，是把动画进度交给手势进度，让界面跟着手指走，而非等手指离开后再播放写好的动画。相册预览与灵感卡片是这套手感最直接的落点：滑动、缩放、返回、回弹，每个细节都在回答同一个问题——用户推一下，界面跟不跟得上。这次提交的意义不在加新功能，而在把“手感”当成值得单独优化的维度。对日记与灵感类应用，手感就是产品的一部分。
