30 秒バージョン: Electron/Chromium シェル アプリケーションの中国語と英語のテキストがすべて消えても、アイコン、画像、カラー ブロックは正常である場合は、次の 2 つのコマンドを試してください。
find ~/.cache/fontconfig -name '*.cache-9' -type l | head # 有输出 → 就是这个问题 fc-cache -f # 修复，然后重启应用
ダウンロード:Debian forky/sid、KDE Plasma 6.7.4(Wayland)。
症状
- CodeBuddy (Electron 37 / Chromium 138): インターフェイス全体には、アイコン、カラー ブロック、ボタンの背景色のみがあります。
すべてのテキストが消えます。 - WeChat Linux バージョン 4.1.1.7 (ミニ プログラム/埋め込みページは Chromium 126 を使用): Qt メイン インターフェイスは完全に正常です。
ライブ ブロードキャスト ウィンドウにはテキストはありません。表示される「絵文字」はフォント レンダリングされていない WeChat ステッカーです。
同じマシン上では、これらはすべて正常に動作します: Edge Dev 158、chromium-browser-unstable 155、
QQ（Electron 40 / Chromium 144）、官方電子クイックスタート（Electron 45）。
排除の方向性 (全員が共通の容疑者であり、彼らの無実が 1 つずつ証明されます):
- フォントの不足はありません:
fc-match 'sans-serif:lang=zh-cn'→ Noto Sans CJK SC、2622 人登録。 - フォント ファイルは悪くありません。Chromium 155 は同じフォント セットを使用して中国語と英語をそのまま表示します。
- これは動的ライブラリの問題ではありません。すべてのアプリケーションの ldd は、それらが同じシステム freetype/fontconfig/harfbuzz にリンクされていることを示します。
- ユーザーの fontconfig 設定、
ld.so.preload環境変数、GPU ドライバーは正常です。
正常/異常をエンジンのバージョンに応じて並べると、境界が全面的にカットされます。
| 応用 | エンジン | キャラクター |
|---|---|---|
| エッジ開発 | クロム158 | ✅ |
| クロムブラウザーが不安定 | クロム155 | ✅ |
| 電子クイックスタート | エレクトロン 45（クロム 14x） | ✅ |
| 電子40（クロム144） | ✅ | |
| コードバディ | 電子37（クロム138） | ❌ |
| WeChat アプレット シェル | クロム126 | ❌ |
クロム ≤138 はすべてが破壊されたことを意味し、≥144 はすべてが生存したことを意味します。
分析する
CDP用(--remote-debugging-port) アプリケーションのレンダリング プロセスに接続し、キャンバス上の各フォント ファミリのサイズを測定します。
テキスト送り幅:
sans-serif => w=0 ← 通用族名：解析归零
serif => w=0
monospace => w=0
cursive => w=0
system-ui => w=187.4 ← 正常
Noto Sans => w=187.4 ← 正常
DejaVu Sans => w=194.1 ← 正常
すべての一般的なファミリ名は解析に失敗しましたが、名前付きフォントはすべて正常でした。これで症状が説明できる
「全か無か」: Web CSS はほぼ常に次のように記述します。 font-family: sans-serif または-apple-system, "Segoe UI", sans-serif(Linux は最終的に一般的なファミリー名に落ちました) そのため、テキストのページ全体が消えてしまいました。
アイコン、画像、SVG、テクスチャはフォント スタックを使用せず、通常どおり表示されます。
その後、それは正常に再現されました (テキストが 5 行、一般的な姓が 3 行、特定のフォントが 2 行)。
~/.cache/fontconfig そこには 5 世代のキャッシュ ファイルが積み込まれています。
xxx-le64.cache-7 真实文件（远古）
xxx-le64.cache-9 -> xxx-le64.cache-12 ← 符号链接（毒点）
xxx-le64.cache-10 -> xxx-le64.cache-12 ← 符号链接（无害）
xxx-le64.cache-11 -> xxx-le64.cache-12 ← 符号链接（无害）
xxx-le64.cache-12 真实文件
各キャッシュ ファイルの最初の 4 バイトには、フォーマットのバージョン番号が記録されます。システム fontconfig 2.17.1 は v9 のみを生成/読み取ります。
v12 は、Chromium 155 によって静的にパッケージ化された fontconfig の更新バージョンです。また、上記の内容は残ります。
「シンボリックリンクの互換性」。タイムラインは以下と一致します:
2026-09-12 08:20:36 dpkg：chromium-browser-unstable 153 → 155
2026-09-12 08:21 cache-12 与兼容符号链接首次落盘
新しいバージョンの fontconfig の互換性設計は次のとおりです。 v12 形式は前方互換性を維持します (アップストリーム fccache.c：
「将来の上位互換性のために不明なオブジェクト タイプを無視する」)、古いバージョン番号へのシンボリック リンク
新しいファイルを指定した後、古い fontconfig とリンク読み取り v12 も解析できます。これはネイティブ システムにコミットします
2.17.1 は完全に真実です – したがって fc-match、fc-list そしてさらに fc-cat 逆コンパイルして比較して、
ポイズン キャッシュとクリーン キャッシュの出力はバイトごとに一貫しており、コマンド ライン レベルで例外は見られません。
悪い点は、CodeBuddy/WeChat が「互換性リンク」機能よりも古い fontconfig をバイナリに静的にパッケージ化していることです。
それは押します cache-9 ファイル名が開かれる → リンクが v12 バイトまで読み取られる → 解析が失敗する → フォント ディレクトリ レコードが 0 にリセットされる。
すべてのディレクトリが影響を受け、一般的な姓によって解析された候補リストは空になります。
3 つの条件:
- 影響を受けるアプリケーションによってパッケージ化された fontconfig は古すぎるため、v12 を読み取ることができません。
- マシン (Chromium 155) には fontconfig の更新バージョンのライターがあり、共有キャッシュをアップグレードし、互換性のあるリンクを残します。
- どちらも同じことを共有します
~/.cache/fontconfig。
コントロール グループ: QQ (Electron 40) は正常です。その組み込みの fontconfig は十分に新しいものです。 Electron 45 が同じ毒キャッシュにヒット
こちらも安心・安全（w=178.9）、有害なリンクを実際のファイルに書き戻すこともできます – 「数回再起動すれば大丈夫です」
形而上学はここから来ています。
テストするには:
| キャッシュツリーの形状 | Electron 37 を使用してテスト済み |
|---|---|
42×v12+ SYM-9→v12(Chromium 155 が書かれたばかりです) |
w=0 ❌ |
| 42×v12 + 42×v9 実ファイル、SYM-9 なし | w=178.9 ✅ |
| 1 つのディレクトリのみ v12 + 有害なリンク、残りは v9 | w=178.9 ✅ (単一ディレクトリの毒は全体的な状況には影響しません) |
結論: v9 と v12 は共存可能です (アップストリームの設計は次のようになり、実際のテストは安定しています)。毒は「v12ファイルの存在」ではありません。
むしろ、そして唯一 cache-9 シンボリック リンクは、古いリーダーが理解できないバイトを指しています。
キャッシュがクリアされないのはなぜですか?各ライターは、自分のバージョン番号に従ってファイル名を綴るだけで、自分のファイルを管理します…fc-cache -f / -r 他のバージョンのファイルはスキャンまたは削除されません (キャッシュ 7/12 を埋め込んで再実行した後に実際にテストしましたが、どれも削除されませんでした)。
解決する
第一選択（手術） – 置く cache-9 v12、Chromium 155 には触れずに、有害なリンクを実際の v9 ファイルに書き戻します。
キャッシュは引き続き有効です。
fc-cache -f
または、核オプションを使用します – 完全に削除し、オンデマンドで再構築します。
rm -rf ~/.cache/fontconfig && fc-cache -f
影響を受けるアプリを再起動すると、テキストが復元されることがわかります。
固定混合状態 (実 v9 + 実 v12 + キャッシュ 10/11 リンク) は安定しています: Chromium 155
再起動しても破壊されることはなく、双方が「有効期限が切れていない」ことを相互に認識します。しかし、Chromium 155 が特定のフォント ディレクトリ (フォント ファイル) を再スキャンすると、
追加、削除、および mtime の変更など）、ディレクトリは再構築されます。 SYM-9→v12散発的な再発として現れます。
3分間のセルフテスト
# 1. 缓存目录有没有混代（正常应该只有一种版本号）
ls ~/.cache/fontconfig | sed 's/.*cache-//' | sort | uniq -c
# 2. 关键判据：cache-9 是不是符号链接？（cache-10/11 是链接无所谓，cache-9 才是毒）
find ~/.cache/fontconfig -name '*.cache-9' -type l | head
# 3. 有输出 → 修复
fc-cache -f
# 4. 重启应用
