在微博等大型團隊中，頁面重構工程師（HTML/CSS）與JS前端工程師是分離崗位。重構工程師產出高質量靜態頁，JS工程師實現交互邏輯。理想狀態是雙方前期充分溝通、約定DOM結構與API契約；現實卻常是：重構階段JS資源未就位，重構師需預判交互實現、預留擴展鉤子、兼顧語義化、兼容性、性能、未來功能擴展——壓力巨大。

實戰案例：倫敦奧運金牌榜模塊的極致優化

需求：首頁右側第一屏，金牌榜模塊，含「展開/收起」切換，展開顯示完整榜單+賽事重點，收起僅顯前三名。

常規實現：兩個獨立DOM結構（展開版/收起版），JS切換顯隱。代碼冗餘、維護困難、首屏渲染負擔重。

優化策略：CSS驅動狀態，JS只管切Class

核心思想：所有狀態的DOM結構一次性輸出，CSS負責顯隱與樣式切換，JS僅切換容器ClassName。將「展開態」與「收起態」所有DOM節點共存於同一容器，通過Class控制顯隱。

HTML結構（簡化）

<div class="turn_olym_on">  <!-- 默認展開態 -->
  <table class="medal_list">...完整榜單...</table>
  <div class="show_more">賽事重點</div>
  <a class="W_moredown" href="#">收起</a>
  <!-- 收起態專用節點，默認隱藏 -->
  <tr class="no_45">...第4-5名...</tr>
  <a class="W_moreup" href="#">展開</a>
</div>

CSS狀態控制

/* 默認展開態：隱藏收起態專用元素 */
.turn_olym_on .no_45,
.turn_olym_on .W_moreup { display: none; }

/* 收起態：隱藏展開態專用元素，顯示收起態元素 */
.turn_olym_off .medal_list tbody tr:nth-child(n+4) { display: none; }
.turn_olym_off .show_more,
.turn_olym_off .W_moredown { display: none; }
.turn_olym_off .no_45,
.turn_olym_off .W_moreup { display: table-row; /* 或 block */ }

JS邏輯極簡化

// 僅需切換容器Class
$('.toggle_btn').on('click', function() {
  $('.medal_container').toggleClass('turn_olym_on turn_olym_off');
});

核心收穫與協作建議

1. 上下游知識互通：重構師理解JS交互模式（事件委託、狀態機、虛擬DOM diff），JS師理解CSS渲染管線、重排重繪、BFC/GFC、語義化HTML。
2. 契約先行：項目啟動時雙方共同定義組件契約：DOM結構、Class命名規範、數據屬性、事件名、狀態Class、響應式斷點。
3. 註釋即文檔：關鍵DOM節點添加標準化註釋（如``），減少口頭溝通成本。
4. 性能預算共擔：首屏渲染時間、CSS/JS體積、關鍵請求數，雙方共同負責，而非互相推諉。
5. 持續學習新標準：HTML5新標簽、CSS3新屬性（Container Queries, :has(), Subgrid）、Web Components、Shadow DOM，雙方需保持同步學習，將新技術落地到實際項目。

元芳，你怎麼看？歡迎在評論區分享你的協作經驗與踩坑教訓。