本地待办应用需用localStorage持久化数据并同步UI状态，通过唯一ID、事件委托、输入校验、属性驱动样式及try-catch容错保障可靠性与体验。
用 HTML + CSS + JavaScript 实现本地待办增删改查
纯前端待办应用不依赖后端，核心就是操作 DOM 和 localStorage。关键不是“能不能做”，而是“怎么让数据不丢、交互不卡、删除不误触”。localStorage.setItem() 和 document.getElementById() 是基础，但真正难的是状态同步和输入校验。
常见错误：用户点两次“添加”导致重复项；清空输入框后回车又提交空任务；刷新页面后勾选状态丢失。这些问题都源于没把 UI 状态和数据状态对齐。
- 每次添加前用
trim()清除首尾空格，空字符串直接return - 每条待办用唯一
id（推荐Date.now() + Math.random()），别用数组下标当 ID，否则删除后下标错乱 - 勾选状态必须存进 localStorage —— 存的是整个任务对象数组，每个对象带
completed: true/false - 渲染列表时用
innerHTML = ''重置再循环拼接，别用append()累加，否则刷新后会重复渲染
用事件委托避免动态元素监听失效
新增的待办项是 JS 动态插入的，如果给每个删除按钮单独绑定 addEventListener('click', ...)，后续新增的按钮根本没绑上事件。必须用事件委托，监听父容器。
典型写法：document.getElementById('todo-list').addEventListener('click', e => { if (e.target.classList.contains('delete-btn')) { /* 找到对应 id 并删除 */ } })。注意判断 e.target 而不是 e.currentTarget，否则点到文字区域就失效。
立即学习“前端免费学习笔记（深入）”；
- 删除按钮建议用
<button type="button">，避免表单默认提交行为 - 点击删除前弹
confirm('确定删除？')，防止手滑 —— 不要用 alert，它阻塞主线程且体验差 - 删除后立即调用
saveToStorage()，而不是等下次“添加”才存，否则关页即丢数据
用 CSS Flex 控制完成态样式与布局响应
完成态不只是加个删除线，还要视觉降权：颜色变灰、字体变细、整行加 opacity: 0.7。这些不能靠 JS 切 class 再写一堆 CSS，而应统一用属性选择器控制。
比如给每条 <li> 加 data-completed="true" 属性，CSS 写 li[data-completed="true"] { text-decoration: line-through; color: #999; }。这样 JS 只需改属性值，样式自动响应，不用管 class 名是否拼错。
- 移动端优先：用
flex-direction: column堆叠按钮，小屏不换行溢出 - 输入框用
width: 100%但加max-width: 500px防 PC 端过宽 - 删除按钮用
margin-left: auto推到最右，比绝对定位更稳，不依赖父容器position
localStorage 容量和兼容性要注意的硬限制
不是所有浏览器都允许无限存。Chrome/Firefox 一般 5MB，Safari 移动版只有 2.5MB，而且是按域名算的。一个含 1000 条待办（每条约 200 字符）的数据大约占 200KB，看起来安全，但实际容易被其他脚本挤占。
更隐蔽的问题是：localStorage 只支持字符串，存对象必须 JSON.stringify()，取出来要 JSON.parse()。一旦数据结构变更（比如加了个新字段），旧数据 parse 会报 SyntaxError，整个应用白屏。
- 读取前加
try...catch包裹JSON.parse()，失败则初始化空数组 - 不要直接
localStorage.removeItem('todos')清空，而是设为localStorage.setItem('todos', '[]')，避免 key 不存在时getItem返回null - IE11 不支持
localStorage在隐私模式下使用，检测方式是try { localStorage.getItem('test') } catch(e) { /* 降级用内存数组 */ }
本地存储终究只是临时方案。真要持久、多端同步、带搜索，就得上 IndexedDB 或连后端 —— 但对“简单待办”来说，localStorage + 合理容错已经够用，前提是别把它当成数据库用。
