一個瓷磚計算器在谷歌商店攢了500下載，開發(fā)者沒急著慶祝，而是把同一套公式塞進了涂料計算——結(jié)果在"單位系統(tǒng)"這個坑里摔了最狠的一跤。

這是獨立開發(fā)者@hotspot-3（化名）在Reddit上復(fù)盤的真實項目。沒有融資故事，沒有增長黑客，只有一個產(chǎn)品經(jīng)理出身的碼農(nóng)，用Flutter搓了個工具類App，然后被"門和窗該扣多少面積"這種細節(jié)逼到重寫數(shù)據(jù)模型。

技術(shù)棧：Riverpod救場，Hive埋雷

項目骨架選得保守：Flutter跨端一套代碼，Riverpod管狀態(tài)流，Hive存計算歷史，SharedPreferences記用戶偏好。Material 3設(shè)計語言，主色調(diào)定了綠色#4CAF50——涂料App嘛，視覺上得讓人聯(lián)想到"新鮮墻面"。

國際化用flutter_localizations，支持多語言切換。聽起來是標(biāo)準(zhǔn)配置，但@hotspot-3后來發(fā)現(xiàn)，真正折磨人的不是翻譯，是翻譯背后的單位系統(tǒng)。

Hive作為輕量級本地數(shù)據(jù)庫，存歷史記錄時他犯了個經(jīng)典錯誤：早期版本只存數(shù)值，沒存單位制。用戶A用公制（米）算完一面墻，切換到英制（英尺）后打開歷史記錄，數(shù)字直接變——2.5米變成了2.5英尺，涂料用量瞬間離譜。

修復(fù)方案是給每條歷史記錄單獨存unitSystem字段。加載歷史時強制使用記錄當(dāng)時的單位制，而非當(dāng)前全局設(shè)置。代碼多了三行，數(shù)據(jù)模型重寫了一下午。

開門開窗：標(biāo)準(zhǔn)尺寸和自定義的拉鋸戰(zhàn)

涂料計算的核心邏輯是"總面積減去門窗洞口"。但"洞口"怎么定義？@hotspot-3調(diào)研后發(fā)現(xiàn)用戶分兩派：一派要快速估算，接受標(biāo)準(zhǔn)尺寸（門2.0×0.9米，窗1.2×1.0米）；另一派較真，非要輸入自家異形窗的精確尺寸。

他最后做了兩套計數(shù)器：標(biāo)準(zhǔn)尺寸用步進器（+1扇門，-2扇窗），自定義尺寸用表單輸入。界面因此復(fù)雜了一倍，但測試用戶反饋"終于不用拿計算器App再算一遍了"。

這里有個反直覺的產(chǎn)品細節(jié)：標(biāo)準(zhǔn)尺寸按鈕的默認數(shù)量是0，而非1。早期版本默認每間房有1扇門，結(jié)果被用戶罵"誰告訴你我家有門？開放式廚房了解一下"。

涂料品牌數(shù)據(jù)庫：自動填充的邊界

覆蓋率的邏輯更微妙。不同品牌、不同型號的涂料，每升能刷的面積差出30%。@hotspot-3建了個小型品牌數(shù)據(jù)庫，選品牌時自動填充典型覆蓋率，但保留手動修改入口。

這個設(shè)計被他自己稱為"防御性妥協(xié)"——數(shù)據(jù)庫不可能覆蓋所有小眾品牌，而專業(yè)用戶往往清楚自家涂料的具體參數(shù)。完全自動化會趕走高端用戶，完全手動又會勸退小白。

最終方案是：自動填充作為"建議值"，輸入框始終可編輯，且編輯后不再被品牌切換覆蓋。狀態(tài)管理用Riverpod的StateNotifier，確保用戶修改的優(yōu)先級高于數(shù)據(jù)庫默認值。

從瓷磚到涂料：同一套公式的不同命運

瓷磚計算器500+下載，涂料計算器上線時間尚短，但@hotspot-3已經(jīng)發(fā)現(xiàn)兩類工具的用戶行為差異。瓷磚用戶更在意"損耗率"——切割浪費、破損預(yù)留；涂料用戶則糾結(jié)"涂刷遍數(shù)"和"底漆/面漆分開算"。

他原本想復(fù)用80%的代碼，實際只復(fù)用了60%。UI框架和狀態(tài)管理通用，但業(yè)務(wù)邏輯層幾乎重寫。瓷磚是矩形堆疊問題，涂料是表面減去洞口問題，數(shù)學(xué)上都不復(fù)雜，復(fù)雜的是用戶對"精確"的定義。

瓷磚用戶能接受"估算"，涂料用戶卻會因為0.5升的誤差給差評——"明明買了5升，刷完剩半桶，你的App讓我多花錢"。

項目已上架Google Play，名稱直白：Paint Calculator: Room & Wall。沒有訂閱制，一次性付費去廣告，定價策略和瓷磚版保持一致。

@hotspot-3在評論區(qū)留了句話，算是給后來者的注腳：「工具類App的護城河不是算法，是你愿意為用戶家的那扇異形窗，多寫多少行防御代碼�！�

你的計算器App里，有過哪些"以為很簡單，結(jié)果重寫三遍"的功能？