这个开发者把500次下载的经验，复制到第2个App时栽了3个坑

500次下载，在应用商店里连水花都算不上。但有人把这组数据当成燃料，又造了一个App——结果在三个意想不到的环节卡了壳。

Flutter开发者@thevivekshukla的经历，像一份被折叠起来的产品手册。表面是"又做了一个计算器"，展开后全是具体的技术债务。他的第一个作品是瓷砖计算器，第二个是油漆计算器，功能逻辑几乎复制粘贴，却在三个地方反复踩坑。

单位系统的幽灵：你以为存的是数字，其实存的是上下文

第一个坑藏在"历史记录"功能里。

油漆计算和瓷砖计算一样，都需要支持公制/英制双单位。但历史记录让事情变复杂了——用户可能今天用米、明天用英尺，而记录必须原样还原当时的场景。

@thevivekshukla的解法是每个历史条目自带unitSystem字段。听起来直白，实现时却要在Riverpod状态流里埋钩子：加载历史记录时，临时覆盖全局单位设置；退出详情页时，再恢复用户偏好。这个来回切换的逻辑，他调了比预期多三倍的测试用例才稳住。

Hive作为本地数据库，在这里暴露了键值存储的局限。没有关系型结构的约束，单位系统和数值的绑定全靠代码层的约定。一个字段漏存，用户就会看到"2.5米"突然变成"2.5英尺"的魔幻场景。

开口扣除的乘法：标准尺寸和自定义尺寸的战争

第二个坑是"门和窗"的交互设计。

计算墙面面积时，需要扣除门窗开口。标准尺寸（门2.0×0.9m、窗1.2×1.0m）是行业惯例，但装修现场总有非标情况。于是界面要同时支持：一键添加标准门/窗，以及手动输入任意尺寸。

麻烦的是计数器。用户可能加了3扇标准门，又手动输入2扇异形门，还要分别显示总数和总面积。@thevivekshukla用了两组并行状态：一组管标准件的计数，一组管自定义尺寸的列表。Material 3的组件库虽然齐全，但把这两组数据塞进同一个视觉层级，他重排了三版布局才不让界面看起来像Excel表格。

更隐蔽的bug在计算顺序。先算总面积再扣开口，还是先逐个墙面扣完再汇总，小数位精度会漂移。他最后强制所有中间计算用双精度浮点，只在最终显示环节四舍五入。

品牌数据库的陷阱：自动填充和手动覆盖的博弈

第三个坑是"智能"与"可控"的平衡。

油漆品牌有官方覆盖率数据（比如某品牌1升刷12平米）。App的理想体验是：选品牌→自动填覆盖率→用户仍可手动改。但这个三态交互（空值/自动值/自定义值）比二态复杂一个数量级。

@thevivekshukla的实现细节是：品牌选择器触发覆盖率字段的"建议值"，同时标记该字段为"可覆盖"状态。用户一旦手动编辑，标记切换为"已锁定"，后续换品牌也不再自动刷新。这个状态机用Riverpod的StateNotifier管理，代码不多，边界情况却攒了一页：如果用户先手动改、再选回"无品牌"，要不要清空？如果自动填充的值和用户手动输入的恰好相同，视觉上如何区分？

他最后选了最保守的策略：任何手动编辑都永久关闭该记录的自动填充，直到用户主动点击"重置"。牺牲了一点智能感，换回了可预测性。

绿色#4CAF50和国际化：剩下的20%工作量

技术栈的其他选择相对常规。Material 3的设计系统省了自定义组件的时间，绿色#4CAF50是品牌色——这个具体色值来自他对"装修工具"认知的直觉测试，没有AB实验。flutter_localizations支撑多语言，但翻译文件的管理（特别是单位相关的复数规则）又占去两天工时。

SharedPreferences存用户偏好，Hive存计算历史，两者分工明确。但他提到，如果重来一次，可能会用Drift统一本地存储，避免两套异步API的上下文切换。

500次下载的经验，没有让他的第二个App少走弯路。单位系统、开口扣除、品牌数据库——三个功能点在不同项目里换了皮囊，核心矛盾却一模一样：状态如何在时间轴上保持一致，界面如何在有限空间里承载复合操作，自动化如何尊重用户的最终裁量权。

这些不是Flutter特有的问题。React Native、SwiftUI、Jetpack Compose的开发者，会在各自的社区里看到相似的踩坑帖。工具链在进化，但产品层面的权衡似乎总是那几个原型。

App已经上架Google Play，名字直白得像功能说明书：Paint Calculator: Room & Wall。没有订阅制，没有社交功能，没有AI推荐。一个计算器，解决一个具体问题，然后安静躺在工具文件夹里——这种产品哲学，在2024年的应用商店里算不算一种叛逆？