draggable="true"仅触发dom节点视觉位移，无法自动将clientx/clienty坐标映射为时间值，必须手动通过dragstart记录原始时间、drop时结合日历行高与getboundingclientrect()换算目标时间点。
原生 HTML 不支持日程事件的拖拽时间调整，必须配合 JavaScript 实现，且需手动处理 dragstart、dragover、drop 等事件，同时精确计算时间偏移。纯 CSS 或仅靠 draggable="true" 无法完成“按分钟/小时调整起止时间”这一核心需求。
为什么 draggable="true" 只能拖元素位置，不能调时间
HTML 原生拖放（draggable 属性）只触发 DOM 节点的视觉位移，不感知日历网格的时间刻度。你拖动一个 <div class="event">，浏览器只告诉你“它被拖到了某个 <code>clientX/clientY”，但不会自动换算成“从 10:00 移到了 14:30”。时间映射必须自己写逻辑。
-
dragstart需记录原始开始时间、持续时长、所在日历行（如第 3 行 = 上午 9–10 点） -
drop时要根据目标容器的getBoundingClientRect()和日历每行高度（比如 60px = 1 小时），反推出新时间点 - 若日历是滚动容器，还得减去
scrollTop，否则拖到下方会偏移 - 不阻止默认行为（
event.preventDefault()）会导致drop事件根本不会触发
用 timeGridDay 类结构做时间映射的实操要点
假设你用的是类似 FullCalendar 的垂直时间轴布局（每 30 分钟一行），或自己写的 <div class="time-slot" data-time="09:30"></div>，关键在于把像素坐标转为时间值。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 先固定每行高度：
const SLOT_HEIGHT_PX = 40（对应 30 分钟） - 在
drop回调里获取目标区域相对于日历顶部的 Y 偏移：const y = event.clientY - calendarEl.getBoundingClientRect().top + calendarEl.scrollTop - 计算落在第几行：
const slotIndex = Math.round(y / SLOT_HEIGHT_PX) - 再查出该行对应的时间：
const timeList = ['08:00', '08:30', '09:00', ...]; const newStart = timeList[slotIndex] - 若要保持原时长，用原始
durationInMinutes推出newEnd，并校验是否超出当日范围
拖拽中实时预览新时间的常见错误
用户拖动时看不到目标时间，就容易误操作。很多人只在 drop 后才更新，体验差。正确做法是在 dragover 阶段就计算并高亮预览位置。
- 别在
dragover里直接修改 DOM（性能差），改用临时div或 CSS::before模拟插入线 - 避免频繁调用
getBoundingClientRect()，可节流到 60fps 内（requestAnimationFrame） - 如果日历有跨天视图（如 week 视图），
drop目标可能是另一个日期列，此时除了 Y 还得算 X 偏移对应哪一天：const dayIndex = Math.round((event.clientX - calendarLeft) / dayWidth) - 移动端没有
drag*事件，必须 fallback 到touchstart/touchmove/touchend，且要考虑 touch-action: none 防止页面缩放干扰
真正难的不是拖动本身，而是把鼠标/触摸点精准锚定到分钟级时间单元——这要求你对日历容器的缩放、滚动、字体渲染差异（影响行高）、甚至 zoom 缩放级别都做兼容。很多线上 demo 在 Chrome 正常，切到 Safari 就偏移 2 行，根源就在没统一用 offsetTop 或 getComputedStyle 动态读取真实行高。
