TechMoon 科技月球
WordPress、SEO 與 AI 工具實測指南
訂閱中國放假補班日曆 chinese-days，公告更新自動同步
chinese-days 是開源的日曆訂閱與 API 工具，把中國大陸法定放假與補班日整理成 iCal 訂閱檔，Google、Apple、Outlook 加入一次，之後公告更新就跟著自動同步。訂閱檔內 2026 年 7 個連假與 6 個補班日全數與國務院公告一致，資料覆蓋 2004 到 2026 年，MIT 授權可商業引用。
用 AI 摘要這篇文章：
跟中國夥伴敲視訊時間，對方丟一句「那週我們放五一連假」，你只能再去查日曆；更麻煩的是三月某個週六上午寄信過去，對方當天就處理了，因為那天是他們的補班日。台灣的行事曆裡沒有這些資訊，每次都要靠對方提醒，或者在搜尋引擎重新查一次放假安排，查完還是只記得住當週，記不住哪個週六要上班。
開源專案 chinese-days 把這件事變成一次性的動作：它把中國大陸的法定放假與補班日整理成一份 iCal 訂閱檔，你在 Google 行事曆、Apple 行事曆或 Outlook 加入一次網址，之後每年的放假安排一發布，日曆就跟著自動更新，不用再手動查。我把訂閱檔整份抓下來，逐日核對過 2026 年的每一個事件，這篇講清楚它裡面到底裝了什麼、資料從哪裡來，以及訂閱之前你該知道的邊界。
我抓下訂閱檔，2026 年一共 13 個事件
訂閱檔是一個放在公共 CDN 上的 ics 檔案，網址就是官方文件上那組 https://cdn.jsdelivr.net/npm/chinese-days/dist/holidays.ics。我實際下載後解析，檔案大小 23,776 bytes，裡面有 41 個日曆事件，涵蓋 2024、2025、2026 三個年份，對應官方文件寫的「近三年」口徑。
拆開看 2026 年的 13 個事件，內容是這樣：
| 日期 | 事件 | 天數 |
|---|---|---|
| 1月1日至1月3日 | 元旦（休） | 3 天 |
| 1月4日（週日） | 元旦（班） | 補班 |
| 2月14日（週六） | 春節（班） | 補班 |
| 2月15日至2月23日 | 春節（休） | 9 天 |
| 2月28日（週六） | 春節（班） | 補班 |
| 4月4日至4月6日 | 清明（休） | 3 天 |
| 5月1日至5月5日 | 勞動節（休） | 5 天 |
| 5月9日（週六） | 勞動節（班） | 補班 |
| 6月19日至6月21日 | 端午（休） | 3 天 |
| 9月20日（週日） | 國慶節（班） | 補班 |
| 9月25日至9月27日 | 中秋（休） | 3 天 |
| 10月1日至10月7日 | 國慶節（休） | 7 天 |
| 10月10日（週六） | 國慶節（班） | 補班 |
有兩個細節值得注意。第一，連續假期在檔案裡是「一個多天事件」，例如春節就是 2 月 15 日開始、為期 9 天的單一事件，日曆上會呈現一整段，不是九個零散的方塊。第二，也是對台灣使用者最有價值的部分：補班日也在檔案裡。6 個補班日各自是一個獨立事件，名稱直接掛「班」字。手動自己建日曆的人幾乎都只會把假期加進去，然後漏掉對方哪個週六要上班，而跨境協作出包的時刻，常常就是那個週六。
檔案的每個事件都帶著固定欄位：時區統一設為 Asia/Shanghai，地點標示北京，事件名稱以「休」或「班」的後綴收尾。這些是 ics 檔案層直接看得到的內容，各家日曆軟體對整天事件的呈現方式略有差異，但名稱、日期與天數是所有軟體共通的。順帶一提，2026 年這 6 個補班日有 4 個落在週六、2 個落在週日，所以別假設補班一定是週六，日曆上有事件就是最準的。
資料準不準？我把這 13 個事件跟專案原始碼裡引用的來源對照過。維護者在程式碼中為每一年都附上了國務院辦公廳放假通知的原文網址，2026 年對應的是 gov.cn 上那份 2025 年 11 月發布的通知，我打開確認連結有效，放假日期、調休安排與訂閱檔逐日一致。2025 年的段落在同一份程式碼裡同樣附有 2024 年 11 月的通知連結，那年春節是 1 月 28 日到 2 月 4 日連放 8 天，搭配 1 月 26 日與 2 月 8 日兩個補班日，與 41 個事件裡屬於 2025 年的那 13 個對得起來。順帶一個小觀察：2025 年國慶撞上中秋、連放 8 天，但因為兩個節日名稱不同，這 8 天在檔案裡被切成三個事件接著排，訂閱歷史年份時看到日曆上連續三格名稱相接，屬於正常現象。也就是說，這份日曆的源頭可以一路追溯到公告原文，不是社群憑印象整理的資料。
補班與調休，看懂這份日曆的前提
如果你跟中國大陸的協作只是偶爾往來，先花三十秒理解這套制度，後面看日曆才會順。
中國的長假是用「調休」組出來的：把放假前後的週末和工作日互換，串成連續假期，代價是某些週六或週日要正常上班，這就是「補班」。以 2026 年春節為例，2 月 15 日到 23 日連放 9 天，但前後的 2 月 14 日與 2 月 28 日兩個週六都要上班。2025 年起春節和勞動節的法定假日各多了一天，這是國務院在 2024 年 11 月的那份通知裡調整的，所以春節才放得出 9 天。
對台灣這邊的實際影響：補班日是對方的上班日，你可以在那天開會、催貨、對帳；連假前最後一個工作日通常是出貨高峰，物流會塞。把這份訂閱加進日曆，這些判斷就不用再靠記憶。
這份日曆是活的：公告之後，更新怎麼到你手上
市面上多數「2026 放假日曆下載」是靜態檔案，年底一到就整份過期。chinese-days 的訂閱檔不同，它是跟著 npm 套件的每次發版重新生成的，背後有一條我看過原始碼的自動化鏈。
鏈是這樣走的：國務院通常在每年 11 月前後發布次年的放假安排；專案在 GitHub 上設了排程任務，每天在幾個固定時段自動去抓公告頁面；一旦偵測到放假安排有變動，就會用 AI 產生對應的資料改動，開一個自動更新分支送出合併請求，同時寄郵件提醒維護者；維護者審核通過、合併之後，套件發布新版本，訂閱檔跟著在 CDN 上刷新；你的日曆軟體接著按自己的頻率更新訂閱，新年度的事件就出現了。
這裡有個誠實的邊界要講清楚：AI 在這條鏈裡只負責起草改動，合併之前有人工審核把關，所以它不是全年無休的即時資料服務。從公告發布到你日曆更新，中間要走完審核、發版、CDN 刷新、日曆軟體更新這幾步。我的推估是等公告後幾天到幾週都有可能，這取決於維護者多快審核。這條鏈也不是紙上設計：專案文件明確引用了第 31 號合併請求，就是這套自動化第一次實際更新 2025 年假期配置的紀錄，換句話說「公告之後自動長出資料」這件事已經發生過，不是還沒兌現的藍圖。
專案本身是活的。npm 套件最新版 1.5.9 在 2026 年 6 月發布，過去一個月的下載量是 18,692 次；GitHub 上有 1,300 多顆星，最近一次合併外部貢獻是 2026 年 7 月。以一個資料型專案來說，這個維護頻率足以支撐「訂閱了就放著」的用法。
三種拿法：訂閱、抓 JSON、裝套件
不寫程式的人：加一條訂閱網址就好。 把 https://cdn.jsdelivr.net/npm/chinese-days/dist/holidays.ics 貼進日曆軟體的訂閱功能：Google 行事曆在「其他日曆」選「從網址新增」；Apple 行事曆在「檔案」選「新增日曆訂閱」；Outlook 則是「新增日曆」裡的「訂閱網頁」。需要英文版事件名稱的話，把網址換成 holidays.en.ics 就行。想補齊更早年份，還有單年檔可以訂，例如 years/2025.ics，支援 2004 年之後每一年。
寫程式但不用 JavaScript：直接抓 JSON。 https://cdn.jsdelivr.net/npm/chinese-days/dist/chinese-days.json 是全量資料，也提供單年檔如 years/2026.json。格式很直白，我抓單年檔來看，內容像是 2026-01-01 對應「New Year’s Day,元旦,1」這樣的三段值：英文節日名、中文節日名、天數旗標，放假與補班都在同一份結構裡，任何語言讀進來就是一個日期對照表，排班系統或 ERP 要併進去都不難。
JavaScript 開發者：npm 裝套件。 套件提供幾個查詢函數，按官方文件的說法，可以判斷某一天對方是否上班、找出一段日期裡的所有工作日，或從某天起算第 n 個工作日是哪一天。最後這個拿來算交期很順手：跟對方約「五個工作日後交貨」，中間撞上國慶連假會自動跳過，不用自己寫例外清單。
只留近三年：2027 年要等 2026 年 11 月公告
檔案只保留近三年。官方文件的說法與我抓到的內容一致：主訂閱檔涵蓋 2024 到 2026，需要更早的年份就用單年檔補。
2027 年還不存在。近兩年的公告都落在 11 月發布，所以 2027 年的放假安排按規律要等 2026 年 11 月的國務院公告，走完上面那條更新鏈才會出現在訂閱裡。年底前看到日曆上沒有 2027 事件是正常的，別急著刪訂閱。
訂閱網址依賴 jsDelivr 這個全球公共 CDN。它是免費且廣泛使用的服務，但畢竟是第三方基礎設施，如果你所在的地區或網路環境對它不友善，訂閱就會失效，這是選擇訂閱制要接受的依賴。
檔案裡有一些 Apple 專屬的擴充標記，例如放假事件會標上工作日改放假的屬性、補班事件會標上替代上班日的屬性，Apple 行事曆對這些標記的呈現會比較完整，其他軟體會忽略它們，基本顯示不受影響。
節氣與農曆是另一包功能。官方宣稱支援 1900 到 2100 年的二十四節氣查詢與農曆陽曆互轉，節氣由公式推算，農曆則使用開源社群的常數表（移植自 Android 的 Android-PickerView 專案），大範圍引用前抽幾個日期核對會更保險。另外要提醒：這份日曆只涵蓋中國大陸的制度，台灣的放假安排本來就不在範圍裡。
供應鏈跟單、跨境協作、看滬深開休市：誰用得到補班事件
判斷要不要訂閱，可以跟「下載一份靜態日曆檔」比較著看。靜態檔的好處是一次匯入就是自己的資料，缺點是年份一到就整份失效，明年還要再找再匯一次，來源品質也每家不同。訂閱的好處是跟著源頭走，資料更新你這邊不用做任何事，缺點是依賴對方持續維護、依賴 CDN 可用。放假這種每年固定更新、又必須年年正確的資料，剛好是訂閱模式最擅長的類型。
跟中國大陸有固定往來的人，這份訂閱幾乎是零成本：加一次網址，換到的是放假與補班兩種事件常駐日曆。供應鏈跟單、跨境專案協作、出貨排程，或是關注滬深股市開休市日的人，都屬於這類。如果你的供應商集中在特定季節出貨，補班日的事件比放假日本身更有用，那是對方趕工的日子。
反之，工作內容純在台灣本地、沒有跨往來的團隊，就不需要它。若你要的是可列印的整年日曆模板或台灣版本假日，站上先前介紹過的 vipcalendar 免費日曆下載 比較對題；想知道重要節日還有多久到，可以看 timepulse 節日倒數計時器；跟中國職缺或中國資料相關的工具，還有 awesome-jobs-china-dev-positions 與 china-divisions-map 兩篇可以參考。
授權與專案狀態
專案以 MIT 授權開源，授權條款檔案就放在 repo 根目錄，無論是拿 JSON 資料做商業應用，還是把訂閱檔引進公司內部系統，都不需要另外授權。資料面的歷史覆蓋從 2004 年起，最新的 2026 年資料對應 2025 年 11 月的國務院公告。上述數字是 2026 年 10 月當時的狀態，之後若看到日曆遲遲沒有新年度事件，先到官方 repo 確認維護狀態再決定是否續訂。
