前一陣子接手一個維護了三年多的 .Net Core 2.1 服務第一件要補的事就是給接口加身份認證。和我預期的一樣方案繞不開 JWT——生成 Token、驗證 Token、把用戶身份安全地傳遞到控制器。JWT 認證在 .Net Core 里已經(jīng)被封裝得比較順手但 2.1 這個版本處在關(guān)鍵的迭代期網(wǎng)上很多教程講的是 3.x 甚至 5.x 的寫法照抄過來經(jīng)常在包版本、中間件順序和 Claim 讀取上翻車。這篇文章是完整的落地記錄覆蓋實現(xiàn)過程、配置參數(shù)和各類踩坑點正在維護 2.1 老項目的人可以直接參考新手也能借此建立 JWT 認證的整體概念。1. 為什么在 .Net Core 2.1 時代還是堅持用 JWT 做認證1.1 從 Session 到 Token認證方式變遷的底層邏輯在單機 Web 時代最常見的認證方式是 Session Cookie服務器內(nèi)存里保存一份會話狀態(tài)瀏覽器每次請求自動帶上 SessionId服務端拿著 SessionId 查會話數(shù)據(jù)。這套機制勝在直觀但在分布式場景下馬上暴露問題請求一旦被負載均衡轉(zhuǎn)發(fā)到不同實例會話狀態(tài)就丟失了。解決辦法要么做 Session 持久化要么開啟負載均衡粘滯會話但無論哪種都會增加架構(gòu)復雜度和維護成本。JWT 的思路完全不同。它把“用戶是誰、能干什么、什么時候失效”這些信息全部編碼進一個自包含的 Token 里服務器不再需要保存任何會話狀態(tài)?？蛻舳税?Token 保存下來每個請求都帶上它服務端拿到后只要驗簽通過、時效沒問題就完全信任這個身份。這種無狀態(tài)特性讓 JWT 在 Web API、前后端分離、微服務架構(gòu)里成了事實標準。.Net Core 2.1 是跨平臺體系中較早的 LTS 版本很多企業(yè)內(nèi)部服務到現(xiàn)在依然在線上運行。給這些老服務補上 JWT 身份認證是大量開發(fā)者都會遇到的改造任務。理解它的原理和落地細節(jié)不只是對付 2.1 項目對后面升級到新框架也同樣有價值。1.2 JWT 令牌的三個構(gòu)成段與一次完整認證流程JWT 全稱 JSON Web Token是一個開放標準RFC 7519。一個 Token 由三段用點分隔的 Base64Url 字符串組成Header、Payload、Signature。Header 聲明簽名算法比如 HS256和 Token 類型Payload 存放聲明信息比如用戶 ID、角色、過期時間Signature 是用密鑰對前兩段內(nèi)容做的簽名確保內(nèi)容沒有被篡改。打個比方Token 就像一張蓋了公章的通行證Header 和 Payload 是證件上印的內(nèi)容Signature 是公章。證件內(nèi)容誰都能讀Base64 只編碼不加密但沒有對應的章密鑰任何人改動內(nèi)容后都補不上新章。所以 JWT 適合做認證而非保密手機號、密碼、身份證這類敏感信息絕不要往 Payload 里塞。一次完整的認證流程圍繞下面幾個動作展開客戶端先調(diào)用登錄接口提交用戶名密碼服務端校驗通過后用密鑰把一堆用戶聲明打包簽成 Token 返回客戶端保存 Token后續(xù)請求在 Authorization 請求頭帶上Bearer Token服務端通過認證中間件驗證簽名、簽發(fā)者、受眾和有效期通過后把用戶身份掛到 HttpContext.User 上之后的授權(quán)判斷和業(yè)務代碼直接讀取即可。這套流程看起來簡單但真正落到 .Net Core 2.1 項目里有很多容易栽跟頭的工程細節(jié)比如 NuGet 包版本、中間件注冊順序、Claim 類型映射、時鐘偏移。這些細節(jié)散落在官方文檔和不同版本的博客里說法還經(jīng)?；ハ嗝苷沓赏暾倪^程記錄比零散搜索效率高得多。下面從環(huán)境準備開始把每一步代碼和選擇背后的理由講清楚。2. 項目準備目標框架、NuGet 包與配置項設(shè)計2.1 創(chuàng)建項目與確認 .Net Core 2.1 的依賴版本很多人在 2.1 項目里加 JWT 失敗第一個坑就是 NuGet 包版本裝錯。.Net Core 2.1 項目文件里TargetFramework要寫成netcoreapp2.1Web API 模板默認引用Microsoft.AspNetCore.App元包但 JWT Bearer 認證中間件并不在元包里需要單獨安裝dotnet add package Microsoft.AspNetCore.Authentication.JwtBearer --version 2.1.2如果使用 Visual Studio 的包管理器搜索Microsoft.AspNetCore.Authentication.JwtBearer后一定要注意版本選擇 2.1.x 系列不要順手選了 3.x、5.x 甚至更高版本。裝錯版本的直接后果是程序集沖突編譯階段就是一片紅色波浪線而且報錯信息晦澀難懂排查起來非常浪費時間。安裝完成后項目里會出現(xiàn)兩個關(guān)鍵依賴Microsoft.AspNetCore.Authentication.JwtBearer提供認證中間件System.IdentityModel.Tokens.Jwt提供JwtSecurityTokenHandler這個生成和解析 Token 的核心類。如果老項目之前裝過System.IdentityModel.Tokens.Jwt的舊版本建議統(tǒng)一升到 5.3.0 以上否則個別簽名相關(guān) API 會找不到行為表現(xiàn)也很不穩(wěn)定。2.2 appsettings.json 里的認證參數(shù)怎么設(shè)計JWT 認證需要配置的核心參數(shù)有四個簽發(fā)者 Issuer、受眾 Audience、簽名密鑰 SecretKey、Token 有效期 TokenExpireMinutes。把它們單獨放進一個配置節(jié)方便后續(xù)替換和讀取{ AuthSettings: { Issuer: MyAuthServer, Audience: MyApiClient, SecretKey: Pssw0rd_Strong_Secret_Key_Replace_Me_2024, TokenExpireMinutes: 30 } }Issuer 表示 Token 由哪個服務簽發(fā)驗證端的 ValidIssuer 必須和生成端完全一致Audience 表示 Token 面向哪個客戶端系統(tǒng)前后端分離項目里通常填前端應用名或網(wǎng)關(guān)名。這兩個參數(shù)看似簡單作用卻很關(guān)鍵它們限定 Token 的使用范圍防止某個服務簽發(fā)的 Token 被另一個毫不相關(guān)的服務無條件接受相當于給憑證劃定了活動邊界。TokenExpireMinutes 直接影響安全性和體驗。內(nèi)部管理后臺可以放寬到 60 分鐘面向 C 端的接口建議 15 到 30 分鐘。時間太長Token 泄露后的風險窗口就大時間太短用戶頻繁被踢下線口碑也受影響。很多團隊后續(xù)會引入 Refresh Token 機制平衡這兩點但有效期這個參數(shù)最好從一開始就做成配置項不要寫死在代碼里。2.3 密鑰的安全生成方法與長度要求密鑰是整個 JWT 方案里最敏感的資源。HS256 算法要求密鑰字節(jié)長度至少 128 位16 個字節(jié)否則運行時拋異常常見的錯誤類型是ArgumentOutOfRangeException提示信息里通常帶IDX10708類似編號大意是 SecurityKey 的 KeySize 不能小于 128 位。生成 Token 時報錯的人特別多基本都是隨手敲了一段很短的字符串當密鑰。我一般建議用 32 字節(jié)以上的隨機串既滿足安全強度也避免未來調(diào)整算法時長度不夠用。生成方式可以這樣在 PowerShell 里執(zhí)行[Convert]::ToBase64String((1..32 | ForEach-Object { Get-Random -Minimum 0 -Maximum 256 }) -as [byte[]])把產(chǎn)出的 Base64 字符串填入配置項注意不要把它提交到 Git 倉庫。我的習慣是開發(fā)環(huán)境放在 appsettings.Development.json生產(chǎn)環(huán)境從環(huán)境變量或部署平臺的密鑰管理服務讀取比如在讀取配置時做一層兜底var secretKey Environment.GetEnvironmentVariable(AUTH_SECRET_KEY) ?? Configuration[AuthSettings:SecretKey];還要強調(diào)一點JWT 的 HS256 屬于對稱簽名簽發(fā)方和驗證方共用同一個密鑰。如果項目里有多個服務要互相驗證 Token密鑰的分發(fā)、輪換必須提前定好規(guī)范不能把明文密鑰外傳或?qū)懺诖a注釋里否則整個認證體系等于沒有防線。3. 核心實現(xiàn)Token 生成、認證注冊與中間件接線3.1 登錄接口里的 Token 生成邏輯Token 生成的核心是先用用戶信息構(gòu)造一組 Claim聲明再用密鑰簽名。為了代碼整潔我先定義一個配置實體類方便依賴注入和測試復用public class AuthSettings { public string Issuer { get; set; } public string Audience { get; set; } public string SecretKey { get; set; } public int TokenExpireMinutes { get; set; } }在登錄接口中用戶密碼校驗通過后把用戶信息封裝成 Claim 數(shù)組然后創(chuàng)建并序列化 Tokenprivate string GenerateToken(UserAuthModel user, AuthSettings settings) { var claims new[] { new Claim(ClaimTypes.NameIdentifier, user.UserId.ToString()), new Claim(ClaimTypes.Name, user.UserName), new Claim(ClaimTypes.Role, user.Role), new Claim(department, user.Department), }; var key new SymmetricSecurityKey(Encoding.UTF8.GetBytes(settings.SecretKey)); var credentials new SigningCredentials(key, SecurityAlgorithms.HmacSha256); var now DateTime.UtcNow; var token new JwtSecurityToken( issuer: settings.Issuer, audience: settings.Audience, claims: claims, notBefore: now, expires: now.AddMinutes(settings.TokenExpireMinutes), signingCredentials: credentials); return new JwtSecurityTokenHandler().WriteToken(token); }這里有幾個容易被忽略的細節(jié)。Claim 相當于是 Token 里聲明的字段建議只放認證和授權(quán)需要的最小信息比如用戶 ID、用戶名、角色、部門手機號身份證這類敏感信息絕對不要放進去因為 JWT 的 Payload 只是 Base64 編碼任何拿到 Token 的人都能直接解碼讀出內(nèi)容。notBefore表示生效時間expires表示過期時間統(tǒng)一用DateTime.UtcNow避免服務器時區(qū)差異導致 Token 生效時間錯亂。SecurityAlgorithms.HmacSha256是這次使用的對稱簽名算法也可以換 HmacSha512但 HS256 在各語言平臺上的解析庫兼容性最好跨服務調(diào)用時不建議為了追求強度隨意換算法。WriteToken負責把內(nèi)存里的 Token 對象序列化成最終字符串這個字符串就是客戶端要保存并在后續(xù)請求中攜帶的憑證。3.2 Startup.ConfigureServices 里的認證服務注冊生成 Token 只完成了一半關(guān)鍵的另一半是讓服務端自動驗證每個請求攜帶的 Token。這個能力要在 Startup 的ConfigureServices里注冊public void ConfigureServices(IServiceCollection services) { services.AddMvc().SetCompatibilityVersion(CompatibilityVersion.Version_2_1); var authSettings Configuration.GetSection(AuthSettings).GetAuthSettings(); services.AddSingleton(authSettings); var key new SymmetricSecurityKey(Encoding.UTF8.GetBytes(authSettings.SecretKey)); services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme) .AddJwtBearer(options { options.TokenValidationParameters new TokenValidationParameters { ValidateIssuer true, ValidIssuer authSettings.Issuer, ValidateAudience true, ValidAudience authSettings.Audience, ValidateIssuerSigningKey true, IssuerSigningKey key, ValidateLifetime true, ClockSkew TimeSpan.FromSeconds(30) }; }); }AddAuthentication注冊認證框架AddJwtBearer把具體的認證處理器掛上去。TokenValidationParameters是驗證參數(shù)集合每一行都對應一個獨立的校驗動作。ValidateIssuer、ValidateAudience、ValidateIssuerSigningKey 這三項建議全部顯式打開不要偷懶只留一個簽名校驗否則將來做安全審計的時候很難交代清楚。ClockSkew很多人不重視。分布式系統(tǒng)里不同服務器時間可能有微小偏差所以認證處理默認允許長達 5 分鐘的時鐘偏移也就是說 Token 過期后最長 5 分鐘內(nèi)依然可能被接受。默認值對普通業(yè)務無所謂但對支付、改密這類敏感接口5 分鐘的安全窗口過大了。實際項目里我統(tǒng)一調(diào)成 30 秒既不敏感也能扛住正常的時鐘抖動。3.3 中間件管道的順序UseAuthentication 到底該放哪光注冊服務還不夠還需要在請求管線上啟用認證中間件。這一步最容易翻車因為平臺不會報錯只是所有帶 Token 的請求都驗證不過。.Net Core 2.1 的 Startup 中Configure方法里正確的順序是這樣public void Configure(IApplicationBuilder app, IHostingEnvironment env) { if (env.IsDevelopment()) { app.UseDeveloperExceptionPage(); } app.UseAuthentication(); app.UseMvc(); }原則一句話UseAuthentication必須在UseMvc之前。可以這樣理解中間件是一串排隊執(zhí)行的關(guān)卡Mvc 一旦接管請求后續(xù)關(guān)卡就沒機會執(zhí)行了。把認證放在 Mvc 前面請求在進入路由和控制器之前Token 就已經(jīng)被解析好并把用戶身份寫進 HttpContext.User控制器里的[Authorize]判斷身份才有據(jù)可依。如果不寫UseAuthentication()會出現(xiàn)一個非常迷惑的現(xiàn)象生成 Token 正常、配置文件看著也沒問題但訪問受保護接口永遠 401。原因就是認證中間件根本沒有運行HttpContext.User 一直是空的授權(quán)過濾器永遠把請求當成匿名訪問處理。排查這種問題時先檢查中間件順序往往比啃代碼快得多。3.4 抽取 JwtTokenHelper 工具類方便復用生成 Token 的邏輯如果在登錄接口寫一遍在重置密碼、第三方登錄之類的接口里再寫一遍代碼很快會散落得到處都是。我的做法是抽一個靜態(tài)工具類把密鑰計算和 Token 生成的邏輯收斂到一處public static class JwtTokenHelper { public static string CreateToken( IEnumerableClaim claims, AuthSettings settings) { var key new SymmetricSecurityKey( Encoding.UTF8.GetBytes(settings.SecretKey)); var credentials new SigningCredentials( key, SecurityAlgorithms.HmacSha256); var now DateTime.UtcNow; var token new JwtSecurityToken( issuer: settings.Issuer, audience: settings.Audience, claims: claims, notBefore: now, expires: now.AddMinutes(settings.TokenExpireMinutes), signingCredentials: credentials); return new JwtSecurityTokenHandler().WriteToken(token); } public static SymmetricSecurityKey GetSecurityKey(string secretKey) { return new SymmetricSecurityKey( Encoding.UTF8.GetBytes(secretKey)); } }這樣登錄接口只需要構(gòu)造 Claim 數(shù)組然后調(diào)用JwtTokenHelper.CreateToken(...)其他接口想要生成輔助 Token 時也一樣。抽成靜態(tài)類在這個場景下足夠簡單沒有內(nèi)部狀態(tài)需要管理沒必要引入額外的注入服務。更重要的是后面寫集成測試時需要快速生成合法 Token這個抽取能直接復用同一套生成邏輯保證測試數(shù)據(jù)和生產(chǎn)環(huán)境的行為完全一致。4. 保護接口并在 Postman 里完成實測4.1 用 [Authorize] 保護接口并讀取當前用戶信息認證注冊完成后給需要保護的 Controller 或 Action 加上[Authorize]特性即可。比如一個查詢用戶資料的接口[Route(api/[controller])] [ApiController] public class UserController : ControllerBase { [HttpGet(profile)] [Authorize] public IActionResult GetProfile() { var userId User.FindFirst(ClaimTypes.NameIdentifier)?.Value; var userName User.Identity.Name; var role User.FindFirst(ClaimTypes.Role)?.Value; var department User.FindFirst(department)?.Value; return Ok(new { UserId userId, UserName userName, Role role, Department department }); } }User.Identity.Name底層就是在讀 Name 類型的 Claim?？刂破骼镒x取當前用戶身份不再需要查數(shù)據(jù)庫所有信息都來自認證中間件解析好的 ClaimsPrincipal這在微服務場景下非常舒服每個下游服務不用維護用戶表也能知道當前操作者是誰、屬于什么角色。同時要注意[Authorize]只表示必須登錄并不限制誰能訪問。角色維度的限制要用[Authorize(Roles Admin)]。另外登錄接口本身必須顯式加[AllowAnonymous]否則會形成死循環(huán)沒 Token 進不去接口而 Token 正是從接口里拿的。4.2 Postman 加 Token 的標準姿勢接口寫完后我用 Postman 做驗證。第一次跑的時候最容易犯的錯是Token 確實生成出來了但請求頭沒帶對。JWT 的標準攜帶方式是 HTTP Authorization 請求頭值必須是Bearer Token格式Bearer 和 Token 之間有一個空格Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...Postman 里也可以直接用 Authorization 選項卡類型選擇 Bearer Token把生成的 Token 粘進去發(fā)請求時它會自動生成正確的請求頭。建議兩種方式都試一遍能加深對 Header 格式的理解。Token 內(nèi)容可以用 jwt.io 這類在線工具解碼檢查一下 Claims 有沒有寫對但注意只拿調(diào)試環(huán)境的 Token 做這種事生產(chǎn) Token 絕不貼到第三方網(wǎng)站上。4.3 不帶 Token、帶錯誤 Token、Token 過期三種場景的響應對比實測不能只看成功路徑。我習慣把典型場景整理成表格逐個打一遍確認整套配置真正生效下面這張表可以直接對應到 Postman 的測試用例里測試場景請求頭預期狀態(tài)碼說明不帶 Token無401匿名訪問被攔截帶有效 TokenBearer 有效 Token200正常通過Token 內(nèi)容被篡改Bearer 改過 Payload 的 Token401簽名校驗失敗Token 已過期Bearer 過期 Token401生命周期校驗失敗密鑰不一致Bearer 其他密鑰簽發(fā)的 Token401簽名校驗失敗Bearer 前綴寫錯直接放 Token 值401認證處理器識別不了我在實測中遇到過一個很隱蔽的問題Token 內(nèi)容復制對了、Bearer 也寫了結(jié)果還是 401。后來發(fā)現(xiàn)是復制 Token 時末尾多帶了一個換行符命令行和腳本環(huán)境下經(jīng)常出現(xiàn)這種隱形字符。遇到 401 先別急著改代碼把請求頭原樣打印出來逐字符檢查一遍低級問題往往藏在這種地方。5. 這套 JWT 方案在真實項目中踩過的坑5.1 Claim 被自動重映射DefaultInboundClaimTypeMap 的坑這是 .Net Core 2.x 時代最有名的一個坑。默認情況下JwtSecurityTokenHandler內(nèi)部維護著入站 Claim 類型映射表解析 Token 時會把短類型名自動改寫成ClaimTypes里的長 URI 類型。例如 Token 里的nameid會映射成ClaimTypes.NameIdentifierunique_name映射成ClaimTypes.Name。這個映射平時很省事但一旦你混用兩種風格就容易翻車。生成 Token 時用new Claim(user_id, ...)這類自定義短名解析時用User.FindFirst(user_id)本來沒問題但如果短名恰好撞進映射表系統(tǒng)會偷偷改成另一個類型名查詢結(jié)果就是 null。有人排查一整天最后發(fā)現(xiàn)是email被映射成了ClaimTypes.Email而代碼里是按短名取的。實際項目里我的建議是二選一別兩邊摻著用。要么全程用ClaimTypes常量生成和讀取靠默認映射工作要么在 Startup 構(gòu)造階段把兩張映射表清空完全按短名讀寫JwtSecurityTokenHandler.DefaultInboundClaimTypeMap.Clear(); JwtSecurityTokenHandler.DefaultOutboundClaimTypeMap.Clear();清空之后行為更可預測尤其適合多個語言服務共用一個 JWT 標準的團隊大家一律按標準短名讀寫不需要了解 .Net 內(nèi)部的 URI 命名空間。還要記住像department這樣的自定義字段不在映射表里讀寫都按寫入時的字符串進行不受這個坑影響。5.2 時鐘偏差導致 Token 提前失效或過期不靈敏不配置ClockSkew時默認值是 5 分鐘。這意味著一個有效期為 30 分鐘的 Token最長實際有效 35 分鐘反過來notBefore也帶同樣的偏移。普通業(yè)務里這問題不大但涉及支付、密碼重置等敏感操作時過期 Token 還能被接受 5 分鐘審計一般過不了。另一個關(guān)聯(lián)坑是ValidateLifetime必須顯式設(shè)成 true。有人抄配置時漏了這行結(jié)果 Token 早已越過過期時間卻依然被當作有效憑證因為校驗器根本沒去查生命周期。這兩個參數(shù)要一起看缺一個都會造成“過期時間形同虛設(shè)”的結(jié)果。我在生產(chǎn)代碼里統(tǒng)一設(shè)ValidateLifetime true、ClockSkew TimeSpan.FromSeconds(30)既不敏感也不至于因為服務器時鐘的小幅抖動影響正常用戶。還有一個容易被忽視的細節(jié)生成 Token 時如果用DateTime.Now而不是DateTime.UtcNow在時區(qū)設(shè)置不同的服務器上exp、nbf會比預期早或晚幾個小時表現(xiàn)就是“Token 明明沒過期卻提示未生效”。這個問題很隱蔽癥狀還隨機建議所有時間相關(guān)操作一律走 UTC。5.3 401、403、500 的區(qū)分與常見定位手段受保護接口出問題第一件事不是改代碼而是分清返回碼。401 表示未認證說明請求根本沒有被識別成登錄用戶常見原因是沒有UseAuthentication()、請求頭格式不對、Token 無效或過期403 表示已認證但權(quán)限不足通常是角色 Claim 缺失或[Authorize(Roles ...)]配置不對500 則說明處理時拋了異常比如密鑰長度不足、讀取 Claim 時空引用等。定位手段按順序來先從 Postman 確認請求頭是不是Bearer Token格式再看 Startup 里認證中間件和 Mvc 的順序然后看服務端日志。JwtBearer 支持通過事件鉤子把認證失敗的具體原因暴露出來配置方式如下options.Events new JwtBearerEvents { OnAuthenticationFailed context { if (context.Exception is SecurityTokenExpiredException) { // Token 已過期可以打日志或者單獨記錄 } return Task.CompletedTask; }, OnChallenge context { // 默認返回空 body 的 401這里可以改成統(tǒng)一 JSON 結(jié)構(gòu) return Task.CompletedTask; } };OnAuthenticationFailed里能看到具體異常類型可以快速區(qū)分過期、簽名失敗還是格式錯誤。OnChallenge在觸發(fā) 401 時執(zhí)行很多團隊在這里改寫響應結(jié)構(gòu)把默認的空 body 換成{ code 401, message unauthorized }這類統(tǒng)一格式前后端聯(lián)調(diào)時會省很多溝通成本。5.4 集成測試里怎么快速生成有效 Token改造完認證后我還會順手寫兩個集成測試防止后續(xù)改動把認證鏈路弄壞。.Net Core 2.1 項目里可以用Microsoft.AspNetCore.TestHost創(chuàng)建內(nèi)存測試服務器不需要真的對外監(jiān)聽端口。測試代碼里最關(guān)鍵的就是快速造出合法 Token。既然前面已經(jīng)抽取了JwtTokenHelper這里直接復用生成邏輯[Fact] public async Task GetProfile_With_ValidToken_ReturnsOk() { var server new TestServer(new WebHostBuilder() .UseStartupStartup()); var client server.CreateClient(); var token JwtTokenHelper.CreateToken( new[] { new Claim(ClaimTypes.NameIdentifier, 10001), new Claim(ClaimTypes.Name, tester), new Claim(ClaimTypes.Role, Admin) }, testSettings); client.DefaultRequestHeaders.Authorization new AuthenticationHeaderValue(Bearer, token); var response await client.GetAsync(/api/user/profile); Assert.Equal(HttpStatusCode.OK, response.StatusCode); }testSettings里配置的密鑰必須和測試服務啟動時讀到的配置一致否則簽名一定對不上。這個測試寫法比把網(wǎng)站真正跑起來更快、更穩(wěn)定CI 環(huán)境里也不會受端口沖突影響。界定好正常路徑、401 攔截路徑、角色校驗路徑三組用例認證鏈路基本就穩(wěn)了。最后再說一句實際操作中的體會JWT 本身不算復雜復雜的是圍繞它的工程化細節(jié)——密鑰管理、過期策略、事件日志、統(tǒng)一響應體都要提前想清楚。尤其是 .Net Core 2.1 這類老版本項目資料少、坑又多把基礎(chǔ)鏈路和典型報錯摸透之后后面不管是升級框架還是對接新服務都會輕松很多。我改造完這套之后又把同樣的模式復制到另外兩個老服務上一次比一次快就是因為把坑都提前記了下來。