`rruleset.totext()` 返回模糊文本（如“2023 every year”）通常源于时间戳精度不匹配或规则逻辑冲突，核心原因是 `exdate` 必须与生成事件的**精确时间点**完全一致，而非仅日期对齐。
在使用 rrule 库构建复杂重复规则时，RRuleSet 是处理「主规则 + 排除日期（exdate）」的理想选择。但其 toText() 方法常返回不符合预期的简略描述（例如 "2023 every year"），而非自然语言表达的完整语义（如 "every day on Monday until August 1 except July 24, 2023"）。这并非 Bug，而是设计限制与时间精度误用共同导致的结果。
⚠️ 根本原因：时间戳必须严格对齐
RRule 所有计算均基于 毫秒级精确时间戳，而非“日期”概念。当你添加一个 RRule（如 DAILY + BYDAY=MO），它实际生成的是满足条件的具体时刻（例如 2023-07-17T08:00:00.000Z），而 exdate(new Date('2023-07-24T08:00:00.000Z')) 只会排除该精确时刻——若该时刻根本不在原始规则生成的事件列表中（比如因 dtstart 时间偏移或 until 截断），则 exdate 无效，整个规则集语义退化，toText() 因无法推导有效模式而降级为笼统描述。
你原始代码中的关键错误：
AI 舌诊面诊问诊医疗系统 + 诊疗商城系统源码是一套结合 AI 辅助诊断与商品转化的健康类程序，基于浩创云、ThinkPHP（PHP）开发，支持微信服务号与 H5 端，适合做中医舌诊面诊问答、健康建议推送以及配套诊疗商品的运营。
dtstart: new Date('2023-07-17T08:00:00.000Z'), // 周一 08:00
until: new Date('2023-07-01T08:00:00.000Z'), // ❌ until 早于 dtstart → 规则为空！until 日期（7月1日）竟早于 dtstart（7月17日），导致 RRule 内部逻辑异常，toText() 失去上下文，只能回退到最保守的年份级描述。
✅ 正确实践：统一时间基准 + 显式验证
推荐将所有时间统一为 当日零点（UTC），消除时分秒干扰，并确保 until 合理晚于 dtstart：
const { RRule, RRuleSet } = rrule;
const rruleSet = new RRuleSet();
// ✅ 主规则：每周一 00:00 UTC，从 7月17日（周一）开始，至 8月1日结束
rruleSet.rrule(
new RRule({
freq: RRule.WEEKLY, // 更合理：DAILY + BYDAY=MO ≡ WEEKLY
byweekday: [RRule.MO],
dtstart: new Date("2023-07-17T00:00:00Z"),
until: new Date("2023-08-01T00:00:00Z"),
})
);
// ✅ 排除日期：必须与生成事件时间完全一致（同为 00:00）
rruleSet.exdate(new Date("2023-07-24T00:00:00Z")); // 排除 7月24日（周一）00:00
console.log(rruleSet.all().map(d => d.toISOString().split('T')[0]));
// → ["2023-07-17", "2023-07-31"] （7月24日被成功排除）
// ? toText() 仍可能不理想？用 toString() + rrulestr 辅助调试
console.log(rruleSet.toString());
// DTSTART:20230717T000000Z
// RRULE:FREQ=WEEKLY;BYDAY=MO;UNTIL=20230801T000000Z
// EXDATE:20230724T000000Z? 提示：RRuleSet.toText() 本质是启发式文本生成，不保证覆盖 exdate/rdate 等高级特性。官方文档明确指出其适用于简单单规则场景。对于生产环境的用户可读性需求，建议：使用 rruleSet.all() 获取实际日期数组，手动格式化为自然语言；或结合 rrulestr(rruleSet.toString()).toText() 验证基础规则，再单独说明排除项。
总结
- toText() 的“每年”输出是库对不可解析规则集的兜底行为，非错误；
- exdate 必须匹配事件生成的精确时间戳（推荐统一用 T00:00:00Z）；
- until 日期必须晚于 dtstart，且 freq 与 byweekday 组合需逻辑自洽（DAILY + BYDAY 效率低，优先用 WEEKLY）；
- 复杂业务场景下，放弃依赖 toText()，转向 all() + 自定义文案生成，才是健壮方案。
