JavaScript 动态计算剩余天数并用 CSS 控制红色预警样式，HTML 仅作结构容器；HTML 本身无执行能力，无法读取时间或自动更新，倒计时必须由 JS 每秒计算差值并刷新 DOM。
直接说结论：用 JavaScript 动态计算剩余天数 + CSS 控制红色预警样式，HTML 仅负责容器结构，纯静态 HTML 无法实现倒计时。
为什么不能只靠 HTML 实现倒计时
HTML 是标记语言，不执行逻辑、不读取当前时间、不触发更新。所谓“倒计时”本质是：每秒重新计算 targetDate - new Date() 并刷新 DOM —— 这必须由 JavaScript 完成。
常见误解是加个 <meta http-equiv="refresh">，但那只是整页重载，不准、耗资源、无法做渐进式预警（比如还剩 7 天变橙色、3 天变红色）。
核心 JS 逻辑：用 setInterval 每秒更新剩余天数
关键不是“怎么写循环”，而是避免时间漂移和时区错乱：
立即学习“前端免费学习笔记（深入）”；
- 别用
setTimeout递归调用（易累积误差）；setInterval更稳，但要在回调开头立刻计算当前差值 - 截止日期统一用 ISO 字符串（如
"2025-06-30T23:59:59"），避免new Date("06/30/2025")在 Safari 中解析失败 - 计算剩余天数时用毫秒差除以
1000 * 60 * 60 * 24，再Math.floor，别用Date.getDay()（那是星期几） - 倒计时归零后要清除定时器：
clearInterval(timerId)，否则继续跑空逻辑
const deadline = new Date("2025-06-30T23:59:59");
const timerId = setInterval(() => {
const now = new Date();
const diffMs = deadline - now;
if (diffMs <= 0) {
document.getElementById("countdown").textContent = "已截止";
clearInterval(timerId);
return;
}
const daysLeft = Math.floor(diffMs / (1000 * 60 * 60 * 24));
document.getElementById("countdown").textContent = daysLeft;
}, 1000);CSS 红色预警：按剩余天数动态切色，别硬编码 class
用 JS 直接操作 style.color 或切换 class 更灵活，比写一堆预设 class（如 days-7、days-3）更易维护：
- 剩余 ≤ 3 天：文字变
#d32f2f（深红），加粗 - 剩余 ≤ 7 天：文字变
#ed6c02（橙色） - 其他情况：保持默认黑灰
- 别用
!important强覆盖，改用更高优先级选择器或内联 style
示例（接上段 JS）：
const el = document.getElementById("countdown");
if (daysLeft <= 3) {
el.style.color = "#d32f2f";
el.style.fontWeight = "bold";
} else if (daysLeft <= 7) {
el.style.color = "#ed6c02";
el.style.fontWeight = "normal";
} else {
el.style.color = ""; // 清空内联样式，回退到 CSS 默认
}容易被忽略的坑：时区、部署环境、DOM 就绪时机
这三个点出问题，倒计时会“看起来正常但数值错乱”：
- 用户本地时区 ≠ 项目要求时区（比如截止是北京时间 2025-06-30 23:59，但用户在纽约，
new Date()拿到的是 EDT 时间）→ 解决方案：后端返回带时区的 ISO 时间（如"2025-06-30T23:59:59+08:00"），或前端统一转为 UTC 计算 - 静态页面部署在 GitHub Pages / Netlify，没服务端，所有时间逻辑必须在浏览器完成 → 别试图用 PHP/Node.js 模板插值“算好再塞进 HTML”，那只是初始值，不会动
- JS 代码放在
<head>里就执行，但getElementById找不到元素 → 必须包裹在DOMContentLoaded或把 script 放在 body 底部
真正难的从来不是写几行倒计时代码，而是让这个数字在不同设备、不同时区、不同网络环境下，始终指向同一个业务意义上的“截止时刻”。
