@匿名用户 感谢您的建议。 关于 CalDAV / ICS 日历订阅到钉钉日历的支持，我们目前有如下评估： 1. **钉钉当前能力限制** 目前钉钉并不支持像 Google Calendar、Apple Calendar 那样，直接通过 URL 订阅外部 ICS 日历。钉钉现有的 CalDAV 功能，本质上是“将钉钉日历同步到其它日历客户端”，而不是“将外部 CalDAV 日历订阅到钉钉中”，两者方向并不相同。 2. **ICS 日历订阅体验问题** 钉钉日历也缺少完整的 ICS 订阅机制。如果需要手动新增节假日日历，往往需要用户逐条创建或维护日历内容，整体操作流程较为繁琐，并不适合作为公共节假日订阅方案长期使用。 3. **与当前场景的匹配度** 节假日信息本身属于标准公共日历数据，而钉钉官方实际上已经维护了自己的法定节假日日历能力，能够满足大部分用户的基础节假日查看需求。因此，从功能重复性和实际使用价值来看，再单独适配一套针对钉钉的 CalDAV / ICS 订阅方案必要性并不高。 综合来看，并非接口侧无法提供 CalDAV 或 ICS 数据，而是钉钉当前并不具备完善的外部订阅能力，因此暂不考虑专门适配钉钉日历订阅场景。更建议有节假日查看需求的用户直接使用钉钉官方提供的节假日日历功能。 再次感谢您的反馈与建议。

@匿名用户 感谢您的建议。 关于钉钉机器人单聊通知（类似聊天窗口直接发送给个人）以及日历订阅场景，我们目前有如下评估： 1. **实现可行性** 技术上是可以实现的，站长在其他项目中正在使用此功能。但如果在当前日历订阅功能中接入该方案，需要贵方的钉钉管理员在钉钉中创建企业内部机器人，首先要创建微应用，再创建机器人，并完成一系列较为复杂的配置流程：包括创建微应用、开通相关权限、接入机器人、配置卡片模板等。同时，还需要提供并维护如 AppKey、AppSecret、机器人 ID、卡片模板 ID 等参数，整体接入链路较长，不仅开发与维护成本较高，也会引入一定的安全管理成本。 2. **与日历订阅场景的匹配度** 当前功能的核心是“日历订阅通知”，本质上更适合做统一推送或批量提醒（如群通知）。如果改为单聊机器人，需要为每一个订阅用户单独建立和维护发送关系，不仅实现复杂，而且在用户规模扩大后，维护成本会明显上升。 3. **使用体验与必要性** 单聊机器人仅支持一对一通知，无法像群机器人一样方便多人同步信息。在日历订阅这种偏公共信息的场景下，群通知已经可以很好满足需求；若改为单聊，不仅显著提高接入门槛，也不会带来明显的体验提升，整体性价比较低。 综合来看，该方案虽然可行，但在日历订阅这一场景下必要性不高，因此暂不考虑接入。现有群机器人通知方案已经能够覆盖大部分使用需求。 如果未来存在明确的“一对一强提醒”需求，我们会再单独评估该方案的可行性。 再次感谢您的反馈与建议。

@匿名用户 啊？我没更新吗？我记得我更新了的，晚点我看一下，没更新的话就补上，谢谢！ 再次感谢您的反馈与建议。

@王杰 感谢您的建议。 关于全站多语言（包括接口与网站界面）的支持，我们目前有不同的规划方向： 1. **接口层（API）** 后续会优先考虑在接口层逐步支持多语言（如返回英文节假日名称等），以便开发者在 i18n 场景下更方便地使用数据。(@HQ 感谢提出的宝贵建议) 2. **网站界面（前端）** 当前网站定位主要是服务中文用户的中国法定节假日查询与 API 文档展示，整体用户群体以国内小型个人开发者为主。因此不会考虑对网站界面进行多语言改造，避免增加不必要的维护成本和复杂度。 如果未来海外用户需求明显增加，我们也会再评估网站多语言支持的可行性，但更建议海外用户调用各大厂更专业的节假日API。 再次感谢您的反馈与建议。

@HQ 感谢您的建议，这个需求确实很有价值，尤其是在 i18n 场景下可以避免部分翻译 API 对中国节日翻译不准确的问题。 目前 API 的节假日数据结构已经稳定运行较长时间，库中累计数据量较大，如果直接在现有数据表中新增字段并逐条补充英文名称，会涉及到历史数据结构调整和大量数据维护，因此短期内暂时不会通过修改数据表字段的方式实现。 不过这个需求我们已经记录下来。后续更可能的实现方案是通过维护一份独立的节日英文词库，在 API 生成响应数据时根据节日名称进行匹配并返回对应的英文名称。这样既可以避免对现有数据表结构进行变更，也能比较灵活地维护节日的英文表达。 如果后续该方案上线，会在 API 文档中进行说明并提供相应字段。 再次感谢您的建议和反馈。

@南威软件 调的那个接口？url是什么，日期是那天？