HTML原生甘特图任务条需用div+CSS定位，核心是将日期范围线性映射为像素：先统一时间戳转毫秒，再按总天数均分宽度；拖拽须放开user-select并处理dragover/drop事件；注意Date解析ISO字符串默认UTC导致时区偏移，应补时区或用构造函数；移动端需改用touch事件替代draggable。
HTML原生实现甘特图任务条：别硬扛，用<div>+CSS定位最可控<p>纯HTML不依赖库也能画出可读的任务条，关键不是“画线”，而是让每个<code>task-bar的宽度、位置、时间刻度对齐真实日期范围。浏览器不认“2025-04-10到2025-04-15”，得你自己算像素——比如把整个甘特区域设为800px宽，对应14天，那每天就是约57.14px，任务从第3天开始、持续4天，就该left: 114.28px; width: 228.56px。
常见错误是直接写死width: 30%或用flex平均分，结果时间跨度和视觉长度完全脱钩。必须基于起止时间戳做线性映射：
- 先统一转成毫秒：
new Date('2025-04-10').getTime() - 算总跨度：
endMs - startMs - 单天像素 =
ganttWidthPx / totalDays（注意用Math.ceil((endMs - startMs) / (1000 * 60 * 60 * 24))算整数天） - 每个任务
left=(taskStartMs - timelineStartMs) / oneDayMs * pxPerDay
拖拽任务条前必须关掉user-select: none
很多人加了draggable="true"却拖不动，其实是CSS里写了user-select: none（为了防误选文字），这会直接禁用原生拖拽事件。只要任务条需要拖拽，就得显式放开：
`.task-bar {
user-select: auto; /* 或 text */
-webkit-user-drag: element;
}`另外，draggable="true"只是开启拖拽源，真正要捕获位移得监听dragover和drop，但注意：drop事件默认被浏览器阻止，必须在dragover里调用e.preventDefault()，否则松手就无效。
立即学习“前端免费学习笔记（深入）”；
-
dragstart里存任务ID：e.dataTransfer.setData('text/plain', taskId) -
drop时取ID，再结合鼠标x坐标反算新开始日期（仍需套用上面的时间→像素换算逻辑） - 别在
drag里实时更新位置——性能差且不准；只在drop后批量重绘
时间精度坑：Date构造函数解析'2025-04-10'默认是UTC零点
写new Date('2025-04-10')得到的是北京时间上午8点（东八区），因为ISO格式字符串被当UTC处理。如果你按本地时间算跨度，结果会偏移8小时，导致任务条错位半天。
将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。
安全做法只有两个：
- 强制补时区：
new Date('2025-04-10T00:00:00+0800') - 用年月日参数构造：
new Date(2025, 3, 10)（注意月份是0起始）
尤其当你的甘特图横轴是“今天起7天”这种动态范围时，new Date().toISOString().slice(0,10)出来的字符串直接喂给Date，就会悄悄偏移。
移动端拖拽基本不可用，改用touchstart+touchmove
drag系列事件在iOS Safari和部分安卓浏览器里支持极差，甚至完全不触发。真要做移动适配，必须放弃draggable，改用手势监听：
-
touchstart记录初始clientX和任务原始时间 -
touchmove计算横向偏移像素，再反查对应几天（除以pxPerDay） -
touchend时提交最终日期，重新渲染任务条
顺带一提：touch-action: none要加在任务条上，否则系统手势（如滑动页面）会劫持事件。
时间轴对齐和跨端拖拽是甘特图最易崩的两个点，前者错一点，所有条全偏；后者漏一种设备，用户就卡死。别想着“先跑起来再优化”，这两处必须从第一行代码就定死逻辑。
