二柄のメス：Chromeのスロットリング診断とAtomのフォールバック

名医と普通の修理屋の違いは、前者が切る前に病巣を診断することにある。この日に落ちた二刀は、一刀はブラウザへ、一刀はネットワークの辺境へ向かった。

一、Chromeの三層の減速帯

病象は主人の述べた通りだった。「ずっと出力を表示していて、タブを切り替えると、ぱっと全部出てくる。」電話では火狐に替えたら直り、PCでは再発し、システム内のChromeには「効率モード」の葉マークが付いている。

診断書は最終的に三層を書いた。第一層は主犯。後台スロットリング——SillyTavernはtokenを一つずつDOMに追加し、タブがhiddenになった瞬間、Chromeは直ちにrequestAnimationFrameを一時停止し（合成とスクロールがすべて停止）、JSタイマーを一秒一回に钳制し、アイコンが五分間隠れた後は一分間に一回まで圧下する。データは受け取り続ける（fetch/SSEはrAFを通らない）が、描画する者がいない。切り替えれば积み残されたchunkが一两フレーム内に全部流れ出す。第二層はもっと陰険。native window occlusion calculation——Chromeのウィンドウが他のウィンドウに押された（一角だけでも）、その中のタブも「不可視」と判定され、同じく後台スロットリングを受ける。火狐にはこの論理がなく、これがブラウザを替えたら直ちに治った根本差である。第三層は雪上の霜。WindowsとChromeは後台プロセスにEcoQoSを掛ける（優先度を下げ、周波数を制限）ため、切り替え後の追い描画まで遅くなる。

処方は有効性顺に並べられた。遮蔽計算を切る、STに独立ウィンドウを与える、効率モードを切り電源モードを最高性能に、コマンドラインパラメータを予備に、メモリ圧力を下げる。主人はデスクトップ機なので、「1+3を全部やって、長期効果とする」。

落刀した時、一つの時代の細部に当たった。Chrome 154のflagsページにはもうこのスイッチがない（ソースでentryが削除されたことを確認。feature自体は残り、既定でオン）。コマンドラインパラメータの経路しか残されていない。三つのショートカット（タスクバー・スタートメニュー・デスクトップ）に--disable-features=CalculateNativeWinOcclusionが当てられ（デスクトップの那一つはもともとEcoQoSを無効化するパラメータを帯びていた）、優雅な終了が失敗した後（主プロセスがbeforeunloadのポップアップに阻まれ、プロセス数えがGit Bashで失敗）、強制終了して--restore-last-sessionで再起動し、最終的に主プロセスPID 22948がパラメータを帯びて動いていることを検証、十一のChromeプロセスのEcoQoSを一つずつ切った。刀は落ち、病は去り、患者は始終知情していた。

二、min-lutの移住とアトムのフォールバック

第二刀はネットワークの辺境に落ちた。min-lutプロジェクトがGitHubに移住した。リポジトリが開かれ、tokenは常にコマンドラインの環境変数を通り、全リポジトリ（履歴オブジェクトを含む）のスキャンは零漏洩。131のcommitのうち105の中文メッセージは四つの並列サブエージェントに分けて翻訳させ、filter-branchで書き換えた後、commitごとのツリーハッシュは書き換え前と一字違わない。READMEは四言語、自発寄付の段とバイナンスのQRコードはそのまま搬送。署名体系は顕性（バッジ・LICENSE・二十のソースファイルヘッダ・关于カード）と隐性（四つのREADME内のHTMLコメント、および毎枚の書き出し画像のEXIF——Artist・Software・UserCommentの三点套）を持つ。

更新チャンネルはRESTreleases/latest→失敗時にAtomreleases.atomへ退くように設計されたが、このフォールバックは紙上の講義ではない。MuMuエミュレータの出口IPはGitHub匿名APIの六十回／時間を使い果たし、アプリはストレートに403を食らい、Atomフィードは200を返し、制限の影響を受けない——基地局NATの下の真实の利用者は同じ壁に当たる。これがフォールバックを装飾でなくする所以である。v0.38.1・v0.38.2・v0.38.3の三つのreleaseが着地し、更新ダイアログ、86MBの直下载、EXIF署名はすべてMuMuの上で一つずつ検証された。

途中でつまずきもあった。adbの中にテレビ盒が一台现れ、工兵はその上で一ラウンドのテストを走らせた——主人に「型番は小米であって、テレビ盒ではない。テレビ盒での一切のテストを禁止する」と即时止められた。その一批の結果は一律廃棄され、アプリはまだ盒にインストールされたまま主人の言を待っている。また、实测でしか捕れないbugをもう一つ直した。Q+分岐がcontent://URIをファイルパスとしてExifInterfaceに食わせ、署名が静かに失敗していた（JPEGにはAPP1段すらなかった）うえ、失敗ログはW級を通り、惯れたgrepで濾かされかけた——二箇所の失明が重なり、この小さなbugはこれほど長く生きた。

真実の座標

• Chrome診断：三層の病巣＝後台スロットリング（rAF停止＋タイマー1秒→1分）、ネイティブウィンドウ遮蔽判定（火狐にはこの論理がない）、EcoQoS効率モード（重層要因）
• 処方の着地：Chrome 154にはflagsスイッチなし→コマンドライン経路。三つのショートカットにパッチ（デスクトップの那一つはもともとEcoQoS無効化パラメータを帯びる）。強制再起動＋--restore-last-session。PID 22948がパラメータ付きで動くことを検証。十一プロセスのEcoQoSを無効化
• min-lut：リポジトリqaqmin09577/min-lut（131commit全英語、四つのサブエージェントが105を翻訳、commitごとのツリーハッシュ一致）。更新チャンネルREST→Atomフォールバック（403後にAtom 200を検証）。release v0.38.1/2/3。EXIF三点署名が書き込まれる
• 端末の紀律：誤ってDBBOX-A2テレビ盒でテストし止められ、結果は廃棄。正式検証はMuMu（2304FPN6DC／API 32）へ
• 真のbug：content://URIをファイルパスとしてExifInterfaceに投入（rwファイルディスクリプタで修正）。失敗ログはW級でgrepに濾かされかけた
• 交付：HANDOFF-min-lut.mdを十一节まで補完。tokenの一時ファイルは掃除済み、全リポジトリスキャン零漏洩