中式美食

不才难以繁此生

HarmonyOS 图片列表滑动卡顿怎么办：中式美食菜谱封面怎么做占位、缓存和失败兜底中式美食的菜谱列表里，封面图不是装饰，它会直接影响用户愿不愿意继续往下滑。最常见的问题不是图片完全加载不出来，而是列表先出现一块空白，过一会儿图片突然顶出来，卡片高度跟着变；再差一点就是网络图失败以后，用一张尺寸不稳定的兜底图把整行挤乱。这个体验看起来像页面卡，实际上很多时候是图片占位、缓存 key 和失败状态没有管住。

不才难以繁此生

ArkUI Tabs 切换后状态丢失怎么办：中式美食分类页怎么保留关键词、筛选和滚动位置中式美食的分类页不是只有一个“切换 Tab”的动作。用户可能在“川菜”里搜了“家常”，又按难度筛了一下，再往下滑到二十几条；这时他切到“收藏”看一眼，再切回来，如果页面又回到顶部、关键词没了、筛选也没了，用户会觉得刚才的操作白做了。这个问题在代码里经常表现为：Tab 一切换就重新初始化列表状态。

不才难以繁此生

NavPathStack 返回错页怎么排查：中式美食详情页从搜索、收藏和推荐进入怎么回到原处中式美食的菜谱详情页会从很多地方进入：首页推荐、搜索结果、收藏页、购物清单、相关推荐。详情页本身看起来是同一个页面，但返回时不能都按同一种方式处理。从搜索进来，应该回到搜索结果；从收藏进来，应该回到收藏列表；从首页推荐进来，应该回到首页原来的区域。

不才难以繁此生

NavPathStack 返回错页怎么排查：中式美食搜索、收藏和推荐入口怎么带来源同一个菜谱详情页，不一定只从首页点进去。用户可能先搜“番茄”，从搜索结果进详情；也可能从收藏页进来；还可能从购物清单里点某个食材，回到对应菜谱。这个时候返回按钮不能写死“回首页”。写死之后，用户刚才的关键词、筛选条件、滚动位置都会丢。中式美食后面做 HarmonyOS 版本时，NavPathStack 要解决的不是“能不能跳转”，而是“从哪里来，就尽量回哪里去”。

不才难以繁此生

HarmonyOS RDB 索引实战：中式美食搜索和购物清单查询怎么避免扫全表中式美食现在的搜索、分类、购物清单和收藏入口，页面上看起来只是几个筛选条件：输入关键词、点一个分类、勾几个食材、再从菜谱详情跳回来。但真正做本地数据时，问题不是“能不能筛出来”，而是“数据多了以后还敢不敢这么筛”。

不才难以繁此生

ArkUI 筛选状态实战：中式美食列表页怎么让关键词、分类和排序不互相打架用户先点“家常菜”，再搜“豆腐”，再切换“最近浏览”，如果每个控件自己维护状态，就会出现列表标题和真实结果不一致。这不是页面上多写几个条件判断就能解决的事。中式美食这类应用，列表、详情、收藏、购物清单、推荐流会互相跳转，状态一乱，用户看到的就是“刚才点过的东西没了”。

不才难以繁此生

HarmonyOS ArkTS 实战｜中式美食用户行为数据：Preferences 持久化、搜索缺口与候选排序做内容型应用时，我们很容易下意识觉得：内容越多越好。放到美食应用里，就是菜谱越多越好，食材越全越好，分类越细越好。这个方向没错，但真做起来会遇到一个更现实的问题：先补什么？

不才难以繁此生

HarmonyOS 实战｜中式美食系列目录：从页面体验到本地数据闭环做 HarmonyOS 应用的时候，最容易卡住的地方不是某一个组件不会写，而是页面一多之后，状态、数据、跳转和视觉风格开始互相影响。

不才难以繁此生

HarmonyOS ArkUI NavPathStack 实战：中式美食详情页多入口返回栈怎么设计中式美食的菜谱详情页一开始只有一个入口：用户在首页点一道菜，进入详情页，看完再返回首页。这个阶段用 pop() 基本够用。问题是项目往后做，详情页入口会越来越多：搜索结果页点进来、收藏页点进来、推荐卡片点进来、分享链接点进来。入口一多，返回就不能再写死。用户从搜索结果进详情页，返回时应该回到刚才的搜索词和筛选状态；从收藏页进来，取消收藏后还要回到收藏列表；如果是分享链接直接打开，栈里可能根本没有上一级页面。

不才难以繁此生

ArkTS 本地数据库实战｜中式美食购物清单：按菜谱来源合并食材数量中式美食前面已经把餐桌方案、买菜清单页和 checkedIds 勾选状态拆过一轮。页面能展示、能勾选以后，下一个更实际的问题会冒出来：如果一桌菜里两道菜都用到葱，清单里到底显示两条，还是合并成一条？如果用户勾选了“葱”，退出页面再回来，这个状态应该从哪里恢复？

不才难以繁此生

HarmonyOS ResourceStr 实战：中式美食菜谱封面怎么统一注册、兜底和缓存中式美食的菜谱封面一开始很好处理：列表卡片里直接写一张图，详情页也能显示。问题是页面一多，图片很快就乱了。同一道菜在首页是一张图，详情页又是一张图；有的菜缺封面，列表里露出空白；推荐卡片尺寸和列表卡片不一样，滚动时高度还会抖。图片看起来只是 UI 细节，但它会直接影响列表稳定性和用户对应用的第一眼判断。

不才难以繁此生

HarmonyOS 端侧应用实战：中式美食如何把资源、路由、存储和视频拆菜串成一条工程链路做一个菜谱类应用，表面看是页面和列表，往深一点看，其实是一个很典型的端侧软件工程问题。中式美食这个项目里，有首页推荐、菜品列表、菜品详情、收藏笔记、最近浏览、视频拆菜、个人厨房这些页面。每个页面单独写出来并不难，难的是页面之间要能稳定流转，数据要能留下来，图片资源不能乱，用户编辑过的内容不能因为切换页面或重启应用就丢掉。

不才难以繁此生

HarmonyOS 实战｜中式美食视频拆菜编辑面板：因子状态、草稿卡片与底部操作条视频拆菜页最难的地方，不是把一段文字拆成几个字段，而是让用户愿意把它改完。很多类似功能做出来以后，看起来像一个结果页：给你一堆识别结果，剩下自己看。中式美食这里更偏向“草稿编辑器”：先把视频或字幕整理成一版可修改的菜谱草稿，再让用户逐条确认、补充、保存。

不才难以繁此生

HarmonyOS RDB 实战｜中式美食菜谱表设计：食材、步骤与购物清单怎么落库中式美食现在已经有菜谱、搜索、收藏、浏览历史、餐桌方案和买菜清单这些入口。页面能跑起来是一回事，数据以后能不能继续扩展是另一回事。如果菜谱一直只当成一个大对象缓存，后面做搜索筛选、购物清单、推荐排序、厨房步骤流时，很多逻辑会慢慢挤到页面和 ViewModel 里。

我是有底线的