Elm可折叠项实现：纯CSS方案对比模型存储ID列表方案优劣

我在实际项目里两种方案都落地过，直接说开发和维护层面的真实差异：

优点 #

• 开发效率高、冗余代码少。不需要在Model里额外定义expandedItems: List ItemId字段，不用写展开/折叠对应的消息类型、update分支逻辑，也不用实现ID存在性校验、列表增删的工具函数，靠CSS的:checked伪类搭配原生checkbox，或者直接用原生<details>标签，几十行代码就能实现基础效果，做简单静态内容的折叠块性价比极高。
• 无状态同步问题。折叠展开的交互状态完全由浏览器原生维护，不会出现Model存储的状态和实际UI显示不一致的bug，也不会给Elm的全局单源状态增加额外维护成本。
• 交互响应更跟手。切换折叠/展开状态时不需要走Elm「消息派发→状态更新→虚拟DOM比对→重渲染」的完整流程，浏览器直接响应CSS变化触发重绘，高频点击时不会有卡顿感，也不会意外触发组件树其他无关区域的重渲染。
• 自带无JS降级能力。即使用户端禁用了JavaScript，基础的折叠展开功能也能正常运行，对基础可访问性场景更友好。

缺点 #

• 状态对业务逻辑完全不可见，联动能力缺失。这是最核心的问题：如果你需要在项展开时拉取子节点数据、把用户的展开偏好持久化到本地存储、做「全部展开/全部折叠」的全局控制、根据路由自动定位展开对应菜单项，纯CSS方案根本无法实现——Elm的业务代码完全感知不到当前哪些项是展开状态，自然没法触发对应的业务逻辑。
• 复杂交互支持极差。要实现展开完成回调、自定义过渡动画、嵌套折叠项的级联控制、按权限禁用部分项的展开能力、展开时自动滚动到视图中心这类需求，纯CSS实现起来要么需要写大量hack代码，要么完全无法实现，最后CSS代码会变得极其冗余难维护。
• 可访问性适配成本更高。靠checkbox实现的方案需要手动补全所有ARIA属性、键盘交互逻辑（支持空格/回车触发、方向键导航）；用<details>标签的话，不同浏览器的默认样式、键盘行为差异很大，要抹平兼容问题花费的精力，反而比直接在Elm中统一管理状态更高。
• 无法保留用户操作状态。页面刷新后所有折叠项都会回到初始状态，如果要记忆用户的操作习惯，最后还是需要把状态同步回Model，平白多出两套状态维护逻辑，反而更容易引入bug。

选型参考：如果是FAQ列表、文章内嵌折叠说明这类纯展示、无业务联动的静态场景，纯CSS方案是最优选择；如果是侧边导航菜单、树形选择器、可折叠数据卡片这类需要和业务逻辑交互的场景，从一开始就把展开状态存在Model里，长期维护成本会低很多。

内容的提问来源于stack exchange，提问作者Robert L