别用 table 写日程/待办页，因其响应式差、交互扩展难、语义错位；应改用 CSS Grid 按时间轴×日期二维建模，分离待办与日程渲染逻辑，并规范 localStorage 数据存取。
直接用 table 布局日程表，90% 会卡在响应式和交互扩展上——不是不能跑，是改一行样式就要重算 colspan、拖拽逻辑全崩、小屏直接堆叠错位。
为什么别用 table 写日程/待办页
浏览器对 table 的渲染逻辑和 DOM 操作限制极多：tr 里不能直接放 div，colspan/rowspan 在 JS 动态插入时极易错行，CSS Grid 的 grid-row 定位和拖拽 dataTransfer 也完全不兼容。更实际的问题是：一旦要加「拖动调整时间」「跨天会议」「点击弹窗编辑」，就得推倒重写。
-
table单元格无法自然撑开高度，时间块高度必须硬编码，而真实日程长度（如 45 分钟 vs 2 小时）需要动态计算行数 - 移动端缩放后文字糊、点击热区偏移，
@media里改table-layout: fixed也没法救 - 语义上，日程本质是「时间轴 × 日期」的二维映射，
table强行套用行列关系，反而掩盖了数据结构
display: grid 日程容器怎么设列和行
核心是把「周一至周日」当列、「时间点」当行，用毫秒级时间戳做锚点，而不是靠 getHours() 硬算。
- 外层容器设
display: grid，列固定为 7：grid-template-columns: repeat(7, 1fr) - 行按 30 分钟粒度切，共 48 行（00:00–23:30），首行留作日期标题：
grid-template-rows: 2.5rem repeat(48, 1rem) - 每个日程
div用grid-column定日期列（如周二 = 第 2 列），grid-row定起止行（如 9:30–10:45 → 第 19 行到第 23 行） - 避免用
minmax()或auto-fit，列宽不一致会导致日程卡片横向错位
待办列表和日程视图怎么共存不打架
别把待办项硬塞进日程格子里——它们数据模型不同：待办是扁平列表，日程是时间坐标+持续时长。强行合并只会让 JS 逻辑越来越绕。
立即学习“前端免费学习笔记（深入）”；
- 用两个独立容器：一个
div#todo-list放未完成/已完成任务（ul+li结构），另一个div#schedule-grid专管日程渲染 - 共享同一份数据源（如数组
tasks），但渲染逻辑分离：待办页只读isCompleted字段；日程页只读startTime、duration、date - 添加新任务时，先存入数组，再根据字段决定是否同步到日程格子——比如带时间的任务才渲染进
grid，否则只进todo-list
localStorage 存日程数据容易漏掉什么
存字符串没问题，但取出来后没 parse 就直接遍历，for...in 会遍历字符串每个字符，不是对象属性。
- 存之前必须
JSON.stringify(tasks)，取出来立刻JSON.parse()，否则tasks.length是字符串长度，不是数组长度 - 时间字段统一用 ISO 字符串（如
"2026-08-04T09:30:00"），别存Date实例——localStorage只存字符串，Date会被转成toString()，时区信息丢失 - 每次写入前先校验数据结构：
if (!Array.isArray(tasks)) tasks = []，防止某次异常写入污染整个存储
真正麻烦的从来不是画出格子，而是时间戳换算时区、跨日事件拆分、拖拽时 dataTransfer 拿不到原始数据——这些坑不踩一遍，很难意识到为什么“简单页面”上线后总在特定时间点出错。
