【半路入行新手 + AI 编程】自研健康管理小程序：记体重模块功能复盘
我是一名半路零基础入门小程序开发的新人，无科班基础、无前辈带教。全程自主完成原创 UI 设计、模块规划、交互梳理、项目骨架搭建。因为代码底子薄弱，AI 编程是我开发路上的核心助力：帮我补全代码、修复 BUG、优化逻辑、拆解复杂功能，更像是一路带我入门的编程老师，支撑我独立做完一整套健康管理全栈项目。
本篇继续更新项目进度，分享第三个核心模块 ——「记体重」的完整设计与落地细节。
一、记体重模块核心功能
- 实时数据仪表盘展示初始体重、目标体重搭配数据仪表盘，直观查看身体管理进度。
- 全方位身体数据记录支持每日体重录入、自动计算 BMI；腰围记录估算体脂率，同时覆盖维度管理、身体成分、代谢指标等多维度记录，满足长期健康追踪需求。
- 数据趋势图表所有记录数据自动分类生成曲线图 + 明细表格，体重、体脂率等变化趋势可视化，每日波动、长期变化一目了然。
- 网格化历史记录历史数据采用 3×3 网格布局展示，排版规整清晰，单格分层展示体重与数据变化，查阅直观高效。
二、开发过程三大真实难点（全文保留不动）
作为零基础自学新人，很多在老手看来不起眼的小问题，对我来说都是反复消耗、反复调试的难题。
难点 1：页面排版对齐问题，强迫症开发的极致折磨
最初历史记录采用纯纵向列分布布局，加上数据变化栏带有上下浮动标识，直接导致整列文字、数字无法统一居中对齐，页面排版错乱。无独有偶，趋势图表下方的数据表格，也因为上下浮动小图标，破坏了整体排版基线，所有内容无法保持同行统一。
为解决这个问题，我做了两处差异化优化：
- 趋势图表页：手动调整整体表格尺寸、文字字号、模块边距，压缩元素落差，最大限度实现视觉对齐；即便还有细微瑕疵，也是当前兼容下的最优解。
- 历史记录页：彻底重构展示逻辑，放弃纵向分列，改用 3×3 网格格子布局，单格内上下分层承载数据与变化标识，从根源规避对齐 bug。
本身有完美主义和强迫症，完全没办法接受 “差不多就行”，一点点排版偏差都要反复修改，硬生生把视觉优化做到了当前极限。
难点 2：图表真机适配翻车，模拟器完美≠真机可用
体重模块最核心、最难调试的就是趋势图表功能。为了适配日渐增多的历史数据，我设计了图表横向滑动右移的逻辑，在电脑模拟器、腾讯云开发工具中预览效果完全完美，显示正常、滑动流畅。
但打包真机测试后直接翻车：手机端版式压缩严重，图表直接模糊甚至消失，完全无法正常使用。无奈只能推翻原有逻辑，重写图表计算代码、重构移动端专属版式布局，反复调试适配比例。这次踩坑也让我总结出关键经验：小程序开发，永远不能只依赖模拟器，真机调试才是最终标准，后续所有开发优化，都会优先以手机真机效果为准。
难点 3：初始体重逻辑设计缺陷，推翻重做迭代
最开始设计逻辑：用户第一次录入的体重固定为「原始体重」，终身不可修改，仅开放目标体重自定义编辑。但实际自用测试后发现严重不合理：减脂、塑形都是分阶段进行，每个人不同周期的起始基数完全不一样，固定初始体重的逻辑完全不符合真实使用场景。
于是彻底重构数据逻辑：将初始体重和目标体重统一改为自定义可编辑模式，用户可以根据自身健身阶段，自由设置每期起始体重，让功能更贴合实际健康管理需求。
难点 4：远期迭代构想 —— 智能体重秤数据联动
其实后期我一直有一个长远构想，希望可以和智能体重秤做数据联动，让体重秤的监测数据直接自动接入到我的记体重模块里，省去手动录入的麻烦。但这块涉及硬件对接与数据连通，已经超出了我目前的技术能力范围，短期内没办法落地实现，只能先当作后续长期迭代的一个期待和目标。
三、开发感悟
从饮食、运动再到体重管理模块，一路开发踩坑不断，但进步也肉眼可见。曾经犯过的错误、踩过的坑，都会变成后续开发的经验，尽量避免重复翻车。非科班 + 半路自学 + AI 辅助的模式虽然缓慢，但足够踏实。后续会继续稳步迭代模块、打磨细节，持续记录新手小程序开发的全过程。
