簡介一份基于Java實(shí)現(xiàn)的中國法定節(jié)假日查詢API源碼包面向需要快速集成節(jié)假日判斷、工作日計(jì)算或排班系統(tǒng)的后端開發(fā)者。項(xiàng)目通過定時任務(wù)自動更新節(jié)假日數(shù)據(jù)并持久化到數(shù)據(jù)庫降低了對第三方公共接口的持續(xù)依賴對外只暴露一個簡潔接口支持按年、按月、按日返回對應(yīng)的節(jié)假日詳情調(diào)用方便、響應(yīng)高效。壓縮包體積僅102KB共包含25個文件其中12個Java文件覆蓋接口層、服務(wù)層與更新邏輯3個SQL腳本提供建表及初始化數(shù)據(jù)2個XML和2個properties文件完成相關(guān)框架配置另有說明文檔和許可證便于閱讀與合規(guī)使用。該資源已有7532人學(xué)習(xí)瀏覽開源免費(fèi)個人維護(hù)但結(jié)構(gòu)完整。學(xué)習(xí)后可獲得自動同步數(shù)據(jù)的調(diào)度實(shí)現(xiàn)、數(shù)據(jù)庫表設(shè)計(jì)、接口封裝方法以及可直接運(yùn)行的示例工程尤其適合在中小企業(yè)或個人項(xiàng)目中快速落地節(jié)假日判斷功能。1. 中國法定節(jié)假日 API別再寫死節(jié)假日清單了這個 Java 工具包幫你自動更新很多做排班、運(yùn)營日歷、薪資計(jì)算的同學(xué)應(yīng)該都有過這樣的經(jīng)歷每年年底拿到下一年的放假安排第一件事就是打開 Excel 手工錄入節(jié)假日、調(diào)休和補(bǔ)班日期。這種寫死清單的方式不僅容易漏而且一旦官方調(diào)整比如臨時補(bǔ)假又要重新改代碼。我最近拆了一個名為 holiday 的 Java 工具包它的定位就是「獲取中國法定節(jié)假日 API自動更新」。核心思路是把節(jié)假日數(shù)據(jù)從官方公告中解析出來封裝成 REST API同時保留手動覆蓋和離線兜底的機(jī)制。對于 Java 后端開發(fā)者、做企業(yè)應(yīng)用集成的人這個資源能省掉你維護(hù)日歷數(shù)據(jù)的一堆麻煩。2. 把節(jié)假日做成接口數(shù)據(jù)從哪來自動更新怎么跑2.1 數(shù)據(jù)源與更新機(jī)制官方公告的解析與轉(zhuǎn)換這個工具包的核心數(shù)據(jù)來源是官方每年發(fā)布的節(jié)假日安排公告。它本質(zhì)上是一個 PDF 或者網(wǎng)頁里面寫了「元旦、春節(jié)、清明節(jié)…」的休假日期和調(diào)休上班日期。直接拿公告里的文字去判斷是否放假經(jīng)常會出現(xiàn)格式不統(tǒng)一、標(biāo)點(diǎn)混亂的問題所以工具包的做法是先人工維護(hù)一份「年份 → 解析規(guī)則」的映射再通過定時任務(wù)去抓取轉(zhuǎn)換成統(tǒng)一的結(jié)構(gòu)化數(shù)據(jù)。自動更新跑起來是這樣一個流程啟動時檢查本地?cái)?shù)據(jù)版本如果本地?cái)?shù)據(jù)已經(jīng)覆蓋當(dāng)前年份就不請求外部源如果發(fā)現(xiàn)新的一年安排已經(jīng)發(fā)布就觸發(fā)一次更新。更新方式不是實(shí)時輪詢而是用定時任務(wù)比如每周一凌晨執(zhí)行一次。因?yàn)楣?jié)假日安排一年才變幾次過度頻繁的請求沒有任何意義反而容易把自己變成耗資源的黑匣子。我一般會在項(xiàng)目里這樣用Scheduled(cron 0 0 2 * * MON) // 每周一凌晨2點(diǎn)檢查一次 public void autoRefreshHolidayData() { boolean updated holidayDataRefresher.refreshIfNeeded(); if (updated) { log.info(節(jié)假日數(shù)據(jù)已更新當(dāng)前版本{}, holidayDataRefresher.getVersion()); } else { log.debug(節(jié)假日數(shù)據(jù)未變化跳過本次更新); } }這段代碼的邏輯很直白refreshIfNeeded()內(nèi)部會先比較遠(yuǎn)端版本號和本地版本號只有版本號不一致才拉取新的數(shù)據(jù)拉取成功后寫入本地存儲文件或數(shù)據(jù)庫然后更新內(nèi)存中的緩存。cron表達(dá)式里的0 0 2 * * MON表示每周一凌晨 2 點(diǎn)執(zhí)行選擇凌晨是為了避開業(yè)務(wù)高峰也避免和運(yùn)維的定時任務(wù)撞車。如果你希望更激進(jìn)可以改成0 0 */3 * * *每三小時一次但我不建議這么做因?yàn)楣?jié)假日數(shù)據(jù)源并不會有這么高的更新頻率。這里有個容易忽略的細(xì)節(jié)版本號不能只依賴文件修改時間因?yàn)槟承┪募到y(tǒng)的時間戳精度不夠而且如果外部源把同一版本的數(shù)據(jù)重新發(fā)布修改時間會變但內(nèi)容沒變。工具包里用的是「年.批次」格式比如2025.1表示 2025 年的第一批數(shù)據(jù)每次解析成功后會生成version字段存進(jìn)數(shù)據(jù)文件比對時只認(rèn)這個字段不認(rèn)時間戳。這算是被坑過才補(bǔ)上的設(shè)計(jì)之前我就是因?yàn)闀r間戳不一致每周都觸發(fā)一次全量拉取白白浪費(fèi)流量。2.2 核心模型節(jié)假日、調(diào)休日、工作日怎么表達(dá)節(jié)假日數(shù)據(jù)光有「是不是放假」是不夠的還要區(qū)分「正常休息的法定節(jié)假日」和「調(diào)休補(bǔ)班的周末」。工具包里用了一個很簡單的模型public class Holiday { private LocalDate date; // 具體日期 private int type; // 0工作日, 1法定節(jié)假日, 2調(diào)休上班日 private String name; // 節(jié)日名稱如“春節(jié)”、“國慶節(jié)” private String description; // 原始公告描述留作排查 public boolean isHoliday() { return this.type 1; } public boolean isWorkday() { return this.type 0 || this.type 2; } }type字段是整個模型的靈魂。很多剛接手的開發(fā)者以為只要標(biāo)記isHoliday布爾值就夠了結(jié)果在計(jì)算「今天是否上班」時把調(diào)休上班日搞反了。注意type 2表示雖然是周末但需要上班這種情況在放假安排里非常常見春節(jié)前一周的周日國慶后的周六。所以判斷上班日必須把type 2也加進(jìn)去否則你的薪資系統(tǒng)和考勤系統(tǒng)就會在調(diào)休日翻車。舉個例子2025 年春節(jié)前的那個周日在很多年份里都是調(diào)休上班日。如果你用isWeekend()去判斷休息那天的數(shù)據(jù)就被判成了休息日考勤系統(tǒng)就會認(rèn)為員工沒有缺勤實(shí)際上大部分人都在上班績效算錯工資也算錯。所以我在代碼評審時看到有人直接寫if (date.getDayOfWeek() DayOfWeek.SATURDAY || date.getDayOfWeek() DayOfWeek.SUNDAY)就會特別謹(jǐn)慎必須讓他加上節(jié)假日類型的判斷。2.3 一個最小可運(yùn)行的查詢示例最簡單的用法是直接調(diào)用工具包的查詢接口不用自己搭 HTTP 服務(wù)直接在代碼里嵌入HolidayService holidayService new HolidayService(); LocalDate date LocalDate.of(2025, 10, 1); OptionalHoliday holiday holidayService.find(date); if (holiday.isPresent()) { System.out.println(holiday.get().getName() 類型 holiday.get().getType()); } else { System.out.println(未配置的日期默認(rèn)按工作日處理); }這里HolidayService是工具包的核心門面它會先去本地緩存里查查不到再查離線數(shù)據(jù)文件。Optional返回的意義是數(shù)據(jù)文件中沒有這個日期的記錄說明它不是節(jié)假日也不是調(diào)休日應(yīng)當(dāng)按普通工作日處理。我在實(shí)際項(xiàng)目里會建議把else分支明確返回Workday而不是讓調(diào)用方去猜否則容易出現(xiàn)空指針。從這段最小示例可以看到工具包把數(shù)據(jù)獲取、解析、緩存都封裝好了開發(fā)人員只需要面向HolidayService編程。但如果你要把它做成一個可供多個服務(wù)共享的 API就得看下一章的接入方式。3. 接入 Java 工程Spring Boot 自動配置與手動調(diào)用兩手準(zhǔn)備3.1 引入依賴與配置項(xiàng)如果項(xiàng)目是 Spring Boot 體系這個工具包可以作為一個 starter 被自動裝配?；驹硎窃趕pring.factories里聲明自動配置類把你需要的HolidayService、HolidayDataRefresher注冊成 Bean。你只需要在application.yml里加幾行配置holiday: api-endpoint: http://your-holiday-api.example/v1 # 遠(yuǎn)端數(shù)據(jù)接口真實(shí)的工具包中會替換為實(shí)際服務(wù)地址 client-token: ${HOLIDAY_CLIENT_TOKEN} # 訪問憑證建議放到環(huán)境變量 refresh-cron: 0 0 2 * * MON # 數(shù)據(jù)刷新頻率 offline-data-file: classpath:holiday-data.json # 內(nèi)置離線數(shù)據(jù)文件 cache-expire-hours: 24 # 內(nèi)存緩存過期時間這些配置項(xiàng)里api-endpoint和client-token是訪問遠(yuǎn)端數(shù)據(jù)源的憑證offline-data-file是內(nèi)置的兜底數(shù)據(jù)即使斷網(wǎng)也能查詢到最近一兩年的節(jié)假日refresh-cron用來覆蓋默認(rèn)的刷新頻率。要注意的是client-token不要硬編碼在配置文件里否則機(jī)密信息容易泄露進(jìn)代碼倉庫這也是一個常見的血淚教訓(xùn)。自動配置類做的事情很簡單就是讀取HolidayProperties然后創(chuàng)建HolidayService和HolidayDataRefresher兩個 BeanBean public HolidayService holidayService(HolidayProperties properties) { HolidayDataStore dataStore new FileBackedHolidayDataStore(properties.getOfflineDataFile()); return new HolidayService(dataStore, properties.getCacheExpireHours()); } Bean public HolidayDataRefresher holidayDataRefresher(HolidayService holidayService, HolidayProperties properties) { return new HolidayDataRefresher(holidayService, properties.getApiEndpoint(), properties.getClientToken()); }這個配置化的好處是開發(fā)環(huán)境可以指向一個 mock 地址生產(chǎn)環(huán)境通過環(huán)境變量注入真實(shí)地址代碼里完全不用感知。而且FileBackedHolidayDataStore保證了離線數(shù)據(jù)文件是只讀的正式刷新會寫入另外的數(shù)據(jù)目錄避免把 jar 包里面的文件搞亂。我在實(shí)際項(xiàng)目里還會加一個spring.profiles.active區(qū)分環(huán)境每個環(huán)境用不同的client-token這樣數(shù)據(jù)訪問的權(quán)限邊界很清楚開發(fā)環(huán)境只能讀mock數(shù)據(jù)生產(chǎn)環(huán)境才能寫真實(shí)數(shù)據(jù)。3.2 手動調(diào)用與 HTTP 客戶端封裝有些老項(xiàng)目沒有引入 Spring Boot或者內(nèi)部網(wǎng)絡(luò)隔離不允許服務(wù)直接外連。這時候你可以不用自動配置直接把這個工具包當(dāng)成普通庫來用或者自己封裝一個 HTTP 客戶端調(diào)用別人發(fā)布的節(jié)假日 API。手動調(diào)用并不復(fù)雜HttpClient client HttpClient.newHttpClient(); HttpRequest request HttpRequest.newBuilder() .uri(URI.create(http://your-holiday-api.example/v1/holiday?date2025-10-01)) .header(Authorization, Bearer getToken()) .timeout(Duration.ofSeconds(5)) .build(); HttpResponseString response client.send(request, HttpResponse.BodyHandlers.ofString()); if (response.statusCode() 200) { HolidayResult result JsonUtil.fromJson(response.body(), HolidayResult.class); System.out.println(result.isHoliday()); }這段代碼有兩點(diǎn)值得注意一是構(gòu)建HttpRequest時給定了 5 秒超時不能讓一個需要快速響應(yīng)的業(yè)務(wù)請求卡在外部服務(wù)上二是對返回結(jié)果做了 JSON 反序列化而不是直接拿字符串去匹配。工具包里通常會附帶一個HolidayResultDTO字段和前面提到的Holiday模型對應(yīng)。如果外部接口返回的字段名和本地模型不一致可以在JsonUtil層做一次映射別把接口的字段名泄露到業(yè)務(wù)代碼里。如果項(xiàng)目里用了 Feign還可以把這段封裝成一個 FeignClient方式也更簡潔。但需要注意 Feign 默認(rèn)的請求超時只有 1 秒對節(jié)假日接口這種低頻數(shù)據(jù)不夠用要單獨(dú)調(diào)大ribbon.ReadTimeout或feign.client.config.remoteService.readTimeout。這個坑特別常見我見過同事用 Feign 調(diào)外部數(shù)據(jù)源接口響應(yīng)慢一點(diǎn)就開始報SocketTimeoutException折騰了好久才定位到是超時配置沒調(diào)。3.3 返回值字段說明與緩存策略拿到接口返回的數(shù)據(jù)后一個合格的實(shí)現(xiàn)應(yīng)該統(tǒng)一轉(zhuǎn)換成下面的格式字段類型說明dateLocalDate日期格式 yyyy-MM-ddtypeint0 工作日1 法定節(jié)假日2 調(diào)休上班日nameString節(jié)假日名稱工作日為WORKDAYdescriptionString原始文本方便排查數(shù)據(jù)溯源這個字段設(shè)計(jì)很實(shí)用。比如你需要給運(yùn)營系統(tǒng)做「今天是否推送營銷內(nèi)容」的判斷只看type 0就可以了如果是薪資系統(tǒng)則要看type 2是否補(bǔ)班。接口返回的數(shù)據(jù)最好不要直接放到調(diào)用方的內(nèi)存里因?yàn)槎鄠€業(yè)務(wù)方會重復(fù)請求導(dǎo)致外部服務(wù)壓力變大。工具包里建議用 Caffeine 做本地緩存CacheLocalDate, Holiday localCache Caffeine.newBuilder() .maximumSize(1000) .expireAfterWrite(24, TimeUnit.HOURS) .build();maximumSize(1000)對一年的日期數(shù)據(jù)365 條綽綽有余expireAfterWrite設(shè)置為 24 小時可以保證數(shù)據(jù)不是永久舊。這里有個細(xì)節(jié)如果你是自建外部 API需要在接口層做一次同樣的緩存否則每天上千萬次請求砸到數(shù)據(jù)源上遲早出問題。緩存之后實(shí)際對數(shù)據(jù)源的真實(shí)請求量會降到每天幾十次完全夠用。另外建議在緩存中同時存儲version字段。這樣當(dāng)業(yè)務(wù)方反饋某個日期不對時你可以快速確認(rèn)當(dāng)前緩存的是哪一批數(shù)據(jù)而不是想當(dāng)然認(rèn)為是最新的。我在生產(chǎn)環(huán)境里加過一個簡單的監(jiān)控每隔一小時讀取緩存 version 和當(dāng)前 data 目錄 version不一致就告警這樣數(shù)據(jù)更新異常能第一時間發(fā)現(xiàn)。4. 避坑指南節(jié)假日接口落地時常見的幾個翻車現(xiàn)場4.1 時區(qū)不對日期差一天現(xiàn)象用接口查詢2025-05-01返回結(jié)果是2025-04-30的節(jié)假日數(shù)據(jù)或者服務(wù)端打印日志顯示日期正常但收到前端請求后多傳了一天。原因前端傳來的日期字符串沒有指定時區(qū)JVM 默認(rèn)時區(qū)被配置成了 UTCLocalDate本身不攜帶時區(qū)但在解析2025-05-01T00:00:00Z時會被 UTC 下推導(dǎo)成前一天的日期。解決在接口入口顯式指定時區(qū)。最簡單的辦法是在 JVM 啟動參數(shù)里加上-Duser.timezoneAsia/Shanghai或者在解析日期時使用LocalDate.parse(dateStr, DateTimeFormatter.ISO_LOCAL_DATE)不要用帶Instant的反序列化。工具包里所有日期字段都強(qiáng)制使用LocalDate避開Date和Instant就是為了杜絕這類時區(qū)偏移。4.2 把調(diào)休上班日當(dāng)成了節(jié)假日現(xiàn)象系統(tǒng)里有用戶在周日請假考勤系統(tǒng)自動按休息日處理但實(shí)際當(dāng)天是調(diào)休上班日結(jié)果漏記了缺勤。原因判斷邏輯只寫了if (type 1) return false沒有考慮type 2的補(bǔ)班場景。很多開發(fā)者一開始會下意識地認(rèn)為「周末 休息日」而調(diào)休上班日恰好打破了這一常識。解決所有涉及「是否上班」的判斷統(tǒng)一走工具包提供的方法而不是自己去組合條件。工具包的方法邏輯是這樣的type 0 || type 2視為工作日出勤。如果你要在自己的代碼里判斷也請把type 2顯式加入。我見過最離譜的翻車是把type 2當(dāng)成普通節(jié)假日寫了一年直到月底對賬才發(fā)現(xiàn)所有調(diào)休那天都不算工資。4.3 自動更新失敗時靜默吞異?，F(xiàn)象數(shù)據(jù)源接口偶發(fā) 500定時任務(wù)捕獲異常后只打了一條 debug 日志半個月后官方發(fā)布了新的調(diào)休方案系統(tǒng)里還是舊數(shù)據(jù)導(dǎo)致后面半個月的排班全部算錯。原因?qū)懚〞r任務(wù)的同事為了省事在整個方法外面加了個大try-catch異常被吞掉沒有告警。自動更新是后臺任務(wù)失敗時往往沒人注意到。解決更新失敗必須拋異?；蛘咧辽俅?error 日志并且必要時接入郵件/企業(yè)微信告警。我一般會把刷新邏輯拆成兩步第一步檢查版本第二步拉數(shù)據(jù)并替換。第三步替換失敗時回滾到舊版本這樣即使失敗也只是暫時沒有新數(shù)據(jù)不會把本地?cái)?shù)據(jù)文件寫壞。另外每次成功更新后記錄版本號方便排查問題。4.4 并發(fā)訪問高卻忘了緩存把外部接口打爆現(xiàn)象線上服務(wù)第一次接入節(jié)假日 API 后QPS 突然飆升外部數(shù)據(jù)源響應(yīng)變慢甚至返回 429業(yè)務(wù)方超時。原因一個請求進(jìn)來內(nèi)部調(diào)用了三次節(jié)假日查詢?nèi)味紱]命中緩存全部打到外部接口上疊加多個業(yè)務(wù)方流量放大了幾十倍。解決參考 3.3 的 Caffeine 方案在本地做好 24 小時緩存。同時還要注意緩存穿透的情況如果有人在循環(huán)里查詢一個不存在的日期每次都返回空也可以把空結(jié)果緩存起來。工具包里提供了一個blackList小機(jī)制專門記錄「確認(rèn)不存在」的日期避免刷無效請求。4.5 跨年切換時用了舊版本數(shù)據(jù)現(xiàn)象每年 12 月 31 日晚上系統(tǒng)里顯示 1 月 1 日是工作日沒有識別出元旦放假或者 1 月 2 日調(diào)休上班日被誤判成休息日。原因工具包的數(shù)據(jù)文件是「年份 批次」管理但調(diào)用方查詢某個日期時沒有校驗(yàn)這個日期是否屬于當(dāng)前已加載的數(shù)據(jù)版本。比如緩存里還是 2024 年的數(shù)據(jù)查詢 2025 年 1 月 1 日自然查不到于是默認(rèn)返回工作日。沒有一條邏輯去識別「跨年數(shù)據(jù)缺失」。解決在HolidayService里加一個「年度邊界檢查」查詢?nèi)掌谌敉碛谝鸭虞d數(shù)據(jù)文件的最大年份就自動嘗試觸發(fā)一次增量更新更新失敗時至少輸出警告日志并返回一個UNKNOWN類型而不是默默按工作日處理。工具包新版本里加了withYearFallback策略本地沒有某一年數(shù)據(jù)時會先檢查有沒有兄弟服務(wù)可以轉(zhuǎn)發(fā)都沒有再去遠(yuǎn)端拉最后才返回默認(rèn)工作日。5. 進(jìn)階離線數(shù)據(jù)兜底與一年數(shù)據(jù)的驗(yàn)證技巧5.1 內(nèi)置數(shù)據(jù)文件和手動覆蓋機(jī)制即使自動更新再穩(wěn)定也要準(zhǔn)備離線兜底。工具包默認(rèn)帶一份holiday-data.json里面維護(hù)了近三年的公開數(shù)據(jù)。你可以直接打開看它的結(jié)構(gòu){ version: 2025.1, updatedAt: 2025-01-10, data: [ { date: 2025-01-01, type: 1, name: 元旦 }, { date: 2025-01-26, type: 2, name: 春節(jié)調(diào)休上班 } ] }當(dāng)外部數(shù)據(jù)源不可用時HolidayService會回落到這個文件。需要注意的是工具包不會自動覆蓋這個內(nèi)置文件而是把新拉到的數(shù)據(jù)寫到一個data/external-holiday.json或者數(shù)據(jù)庫中。這樣做的原因是避免每次升級 jar 包都把官方新數(shù)據(jù)丟掉。手動覆蓋時你只需要把當(dāng)前年份的數(shù)據(jù)寫到外部數(shù)據(jù)文件服務(wù)會優(yōu)先讀取外部數(shù)據(jù)本地內(nèi)置數(shù)據(jù)作為最后兜底。5.2 用已知年份的放假安排驗(yàn)證接口準(zhǔn)確性拿到任何一套節(jié)假日數(shù)據(jù)我的習(xí)慣是先驗(yàn)證再接入。不要相信它自稱是「自動更新」就放心用每年都有數(shù)據(jù)源把節(jié)日名稱寫錯或者漏掉調(diào)休。驗(yàn)證方法很簡單選一個已經(jīng)過完的年份比如 2024 年把當(dāng)年放假安排摘出來逐個和工具包的返回值對比。ListLocalDate knownHolidays List.of( LocalDate.of(2024, 1, 1), LocalDate.of(2024, 2, 10), LocalDate.of(2024, 10, 1) ); for (LocalDate date : knownHolidays) { Holiday holiday holidayService.find(date).orElse(null); if (holiday null || holiday.getType() ! 1) { throw new IllegalStateException(驗(yàn)證失敗 date); } }這段代碼只驗(yàn)證了三個關(guān)鍵點(diǎn)實(shí)際你可以寫成遍歷全年每一個周末、每個已知補(bǔ)班日的數(shù)據(jù)集。我的經(jīng)驗(yàn)是至少要準(zhǔn)備三組節(jié)假日、調(diào)休上班日、普通周末每組各挑幾個代表日期。這樣能一次性發(fā)現(xiàn)模型層面的問題。5.3 我的一個強(qiáng)制習(xí)慣上線前全量跑一遍自檢接手這個工具包后我給自己立了一個規(guī)矩凡是接節(jié)假日相關(guān)功能的項(xiàng)目上線前必須跑一遍全量自檢。所謂全量自檢就是遍歷下一年的每一天把工具包返回的類型和一份人工維護(hù)的「可信答案」對比任何不一致都直接阻斷發(fā)布。這份可信答案可以放在測試資源里由組長或產(chǎn)品人工維護(hù)不作為業(yè)務(wù)邏輯的一部分。自檢代碼其實(shí)不復(fù)雜LocalDate start LocalDate.of(2026, 1, 1); LocalDate end LocalDate.of(2026, 12, 31); for (LocalDate d start; !d.isAfter(end); d d.plusDays(1)) { int expected trustedAnswer.getType(d); int actual service.getType(d); if (expected ! actual) { throw new IllegalStateException(日期 d 類型不一致expected expected , actual actual); } }從那以后我每次接這類功能都會強(qiáng)制走一遍全量自檢寧可多花十分鐘換一個放心。這個習(xí)慣救了我好幾次比如有一次工具包新版本數(shù)據(jù)源字段映射反了全量自檢直接攔住了發(fā)布。希望這個思路也能幫到你拿著這個 holiday 資源包接入之前先把它當(dāng)作一個「數(shù)據(jù)準(zhǔn)確性審計(jì)工具」而不是一個黑匣子直接信任。本文還有配套的精品資源點(diǎn)擊獲取