工作總結
發表時間：2026-04-03孩子王轉正工作總結。
入職孩子王九十天，試用期最后一天下班前，我把促銷計算模塊的最后一個單測用例跑通，覆蓋率剛好卡在71.3%——離目標還差一點，但至少核心的三重疊加場景全過了。這三個月，主要任務是接手交易鏈路里的“促銷計算”老模塊，把它從一碰就碎的瓷器改成能扛住雙十一的鋼筋水泥。下面把這期間拆過的雷、擰過的螺絲、跟同事吵過的架，老老實實捋一遍。
一、老代碼的債，新方案的路 ?
剛進來第一周，leader扔給我一個故障單：某筆訂單用了“滿300減50”疊加“母嬰品類95折”，最終支付金額算出來是負數。我順著調用鏈找，點進去七層——從OrderPriceCalculator到PromotionDiscountService再到CouponApplyServiceImpl，最后在MemberLevelUtil的一個靜態方法里發現，折扣金額被轉成了double，加減乘除丟精度了。改完那一行代碼，我把涉及金額計算的所有類搜了一遍，類似問題還有五處。
老方法的坑不止精度。促銷規則全放在數據庫里，每個商品每類促銷都要單獨查表。一個訂單十件商品、五種促銷，就是五十次數據庫往返。我統計過，日常平均響應280毫秒，大促預演時沖到600毫秒以上。更離譜的是，優先級判斷的邏輯被復制粘貼在三個不同的Service里，修一個bug要改三處，改漏一處就出事。
新方案分三步落地。第一，把促銷規則全部預熱到本地Caffeine緩存，活動規則十分鐘過期，商品快照半小時過期，緩存容量從默認的5000條擴大到50000條——這個數字是壓出來的，再大GC受不了，再小命中率不夠。第二，重寫優先級引擎，把互斥、疊加、階梯三類邏輯抽成獨立的PromotionChain，每個促銷實現統一的calculate接口，新加活動只需要加一個實現類，不用改老代碼。第三，引入訂單快照的預計算字段，下單前一次性把商品所屬品牌、類目、價格檔位加載到內存，避免逐條查。
上線不是一把梭。我先在預發環境把新老引擎雙寫跑了三天，每天隨機抽一千個真實訂單號對比計算結果。第一天誤差率0.3%，全是精度問題——新引擎用ROUND_HALF_EVEN，老引擎用ROUND_HALF_UP。統一改成ROUND_HALF_UP后，誤差率降到0.02%，剩下的是因為緩存預熱時機不一致導致的瞬時不匹配。又調了兩天，把緩存加載改成應用啟動時強制預熱，然后放量1%的流量做灰度，觀察四小時無報錯，逐步放大到5%、20%、50%、100%。最終上線后，同樣場景下平均響應時間從280毫秒壓到了42毫秒，TP99從520毫秒降到了86毫秒。壓測報告出來那天，我對著數據愣了三秒，然后去泡了杯速溶咖啡——比中彩票實在。
二、一個真實的故障：晚高峰前的四十分鐘 ?
十月十七號，周四，下午五點四十。我剛準備去接水，手機監控彈窗——促銷計算模塊P99耗時飆升到1.2秒。打開SkyWalking，calculateMemberExclusivePrice這個方法調用量暴增了二十倍，每筆訂單都在掃一張全表。
查日志發現，運營下午四點配了一張“育兒顧問專享價”表，但配置邏輯出了問題：不是按會員ID映射，而是用手機號明文做LIKE模糊查詢。當時離晚高峰只剩不到二十分鐘，改代碼根本來不及。我直接在生產配置中心把member.exclusive.enable這個開關設為false，強制走降級邏輯——統一按普通會員折扣處理。五分鐘后，耗時回落到正常水平。
然后我讓運營導出那張表，寫了臨時腳本把手機號轉成會員ID的哈希映射，存到Redis Set里，同時加了一層布隆過濾器防止緩存穿透。晚上九點半，重新打開開關，觀察了半小時，一切正常。那天晚上我走的時候，運維同事跟我說：“下次你直接打電話叫我就行，不用自己改配置。”我說：“下次我提前把腳本寫好，你幫我跑。”
事后我補了兩件事：第一，在代碼里對所有外部數據源依賴加了熔斷和降級開關的標準化注解，以后新加促銷類型必須默認帶降級邏輯才能合并。第二，跟運營約定，任何新配置上線前必須先過一遍“手機號轉ID”的自動化校驗腳本，否則不接收。這兩件事算不上什么技術突破，但真到火燒眉毛的時候，就是命。
三、質量驗收和設備維護那些規矩 ?
我們每個迭代結束要過一次“故障演練清單”，不是走形式，是真摔。清單上列了十二條場景，比如：Redis集群全掛、會員服務超時、緩存擊穿、促銷規則配置為空……每一條都要驗證系統能在規定時間內降級或自愈。上個月演練“Redis掛掉”這一項時，我發現本地緩存的淘汰策略有問題：maximumSize設得太小，高并發下頻繁觸發淘汰和重載，反而比直接查庫還慢。調整到50000條后，結合差異化過期時間——活動規則十分鐘、商品快照半小時——才真正穩住。
設備維護這塊，我接手時前輩們習慣手動top、free看資源。我搭了一套Grafana看板，盯三個核心指標：GC暫停時間、年輕代晉升速率、接口TP99同比曲線。有一回發現晉升速率異常飆高，順著查下去，是日志里不小心打出了完整的促銷規則JSON對象，一條規則能有兩百多行。刪掉那行日志，GC頻率從每分鐘12次降到3次，停頓總時長從800毫秒降到120毫秒。
代碼審查也有規矩。我們要求所有金額計算必須用BigDecimal，所有外部調用必須設超時，所有配置變更必須走配置中心而不是硬編碼。有一次code review，一個同事把超時時間寫成了30秒，我說“你見過哪個用戶等三十秒不關頁面？”改成3秒，配合重試兩次。后來線上真有一次會員服務抖動，3秒超時觸發重試，第二次成功了，用戶沒感知。
四、跟測試同事的“友好交流” ?
第二周迭代，測試提了個bug，標題寫著“促銷計算錯誤，優惠金額多減了0.01元”。我看了半天代碼，覺得自己邏輯沒問題，就去找測試。她打開訂單詳情給我看，我一眼就發現——她造的那個商品原價是9.99元，滿減規則是“滿10減1”，系統沒給優惠，她覺得應該給。我說“滿10減1，9.99不滿10，當然不減。”她說“用戶會覺得就差一分錢，你們應該四舍五入。”那天下午我們倆在會議室吵了十分鐘，最后產品經理過來拍板：規則不改，但前端加提示“還差0.01元即可享受優惠”。這事讓我學到一個教訓——技術上的正確不等于用戶體驗上的正確，有些邊界條件得跟產品對齊，不能光看需求文檔。
后來我在代碼里加了一層“接近閾值”的預判斷，比如滿減差5%以內就在日志里打一個WARN，運營可以據此調整活動門檻。
五、文檔和回滾：沒出事不等于沒準備 ?
重構完促銷引擎，我寫了遷移指南，放在團隊Wiki上，內容包括：新舊數據結構對照表、配置項說明、灰度放量步驟、常見問題排查。上周一個新來的同事接手了另一個模塊，照著我的文檔處理了類似的緩存問題，在群里說了句“還好有這篇”。我覺得這比任何表揚都實在。
回滾預案我單獨寫了一頁。核心就一句話：配置中心里有一個promotion.engine.version開關，設為v1用老引擎，v2用新引擎。一旦新引擎大面積算錯，十秒鐘內切回v1，損失不超過一輪緩存刷新周期。這個開關上線前演練過兩次，第一次切換耗時15秒（因為有一處依賴沒解耦），第二次優化到4秒。
六、往后怎么干 ?
接下來兩件事。一是把促銷計算模塊的單測覆蓋率從71.3%提到85%以上，重點補“滿減+折扣+優惠券”三重疊加場景下的尾差計算——目前這個場景只有3個用例，要補到30個以上，覆蓋所有可能的價格小數點組合。二是跟運維一起把彈性伸縮策略從基于CPU改成基于TP99，規則是：當TP99連續兩個采樣點超過100毫秒，自動擴容一臺實例；低于50毫秒且持續十分鐘，縮容一臺。這個閾值是拿雙十一預估流量的六倍壓測數據擬合出來的，不是拍腦袋。
轉正申請寫完了，但活兒沒完。明天早上還有個代碼審查會，要過一遍新來的同事寫的“拼團促銷”邏輯。我打算在會上問一個問題：“拼團失敗退款時，已經分攤到每個人頭上的優惠怎么收回？”如果他答不上來，我會把方案寫清楚，貼到Wiki上。這才是轉正后的正常狀態——不是慶祝，是繼續干活。
- 為了您方便瀏覽更多的工作總結網內容，請訪問工作總結
