题目重点：从公开的“类似社交产品发帖、只实现 UI、不接网络”要求出发，拆现有代码阅读、草稿状态、交互、测试与代码可维护性。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 训练版页面有文本输入、字符计数、提交按钮和本地成功状态；这些具体控件只是可验证的实现范例，不声称来自未公开题面。
- 不发 HTTP 请求、不虚构服务端发帖成功；点击提交只触发本地状态改变或调用 starter 已有回调。
- 现有仓库的架构优先于个人喜好，需先确认是 Compose、XML View、MVVM 还是其他方案。
解题路线
- 先运行 starter 并读入口 Activity/导航、已有主题组件、状态管理和测试脚本；锁定最小改动面，而非新建一套平行架构。
- 把状态分成 `text`、`isValid`、`isSubmitting`（若本地有动画）与 `submittedDraft`。UI 只渲染状态并抛出事件；校验规则统一放在可测试层，避免按钮 enable 与提交 handler 对空白/长度理解不同。
- 本地提交后展示明确反馈，保持草稿或清空草稿要由需求决定；屏幕旋转/进程重建时草稿不丢，常用 saved state 或现有 ViewModel 路径。测试空白、接近长度边界、连续点击和系统返回。
- 用现有 design system 处理键盘、触控目标、内容描述、字体放大和高对比；若题目只给功能，先保证可运行与可访问，再微调像素。代码审阅时能解释为什么组件边界、状态单向流和测试方便后续接入真正网络层。
手动走一遍
训练例用户输入 `Hello`，本地计数为 5，按钮可用；点击提交后展示本地确认并按约定清空草稿。若输入全空格，训练版先 trim 后禁止提交。旋转设备再返回时，未提交草稿仍在；这条重建行为需要用实际 starter 的状态机制实现。
规模与取舍
文本校验 O(L) 时间，L 为草稿长度；UI 状态和渲染通常 O(L) 级别。真正瓶颈是仓库理解和交互质量，非算法性能。超长草稿的逐字符高亮或实时 Markdown 预览若未要求，不应增加复杂度。
易错点与追问
容易失分的边界
- 新页面能看但未接入原导航或主题，实际入口不可达。
- Compose/XML 状态与 ViewModel 状态双向乱写，旋转后草稿丢失。
- 按钮禁用条件与提交时校验不一致，导致空白帖。
- 只靠截图确认，未测试键盘、返回、字体放大和快速连点。
- 把本地 UI 题扩展成需要数据库/网络的完整社交服务，偏离公开范围。
继续深挖
- 若下一阶段接网络发布，如何在 UI 层表示 pending、失败重试与幂等提交？
- 图片附件加入后，草稿保存与权限请求如何分层？
- 如何在不改原 starter 架构的情况下提高 UI 测试稳定性？
