代码

ルール： マークダウン構造を保護する。 URLやコードを翻訳しない。 追加のコメントなしで翻訳された内容を返す。 阿珏Blog十周年活動が無事に終了しました。 今年の参加者は私の予想を超えていました。活動期間中、群グループで手がかりやヒントを交換し、多くの人々が無事に最終的な報酬を手に入れました。2年前から計画を立てていたものが本当に誰かが真剣に遊んで終わったことに、とても嬉しいです、AIのサポートがあったとはいえ。 もしまだ遊んだことがない場合は、まず活動原文を見てください。これはすべての答えを直接公開し、以下は完全なストーリーです。ゲーム中にはあなたの認識を覆すような多くの知識内容があります。 全体フロー 拆弾専門家 → エントリーポート → ブラックアウト画像の調整 → ログインとキャプチャー → 偽Cloudflareページ → PDFにZIPを隠す → GalGame対話で手がかりを見つける → 数字を推測 → 二次元コードをスキャン → 異なるものを見つける → 明暗モードのアルバム → パズル → 保险庫。 第0関：拆弾専門家 最初の関節は小さな前菜です。ページには4本の異なる色の線とカウントダウンがあり、どの一本を切るかを慎重に判断するように見えます。 しかし、正しい答えはありません。どの一本を切っても爆発します。爆発後、ページは貴重なアルバムが粉々になったことを示し、片付けるよう指示します。 次にやるべきことは明確です：支線タスクを引き出し、後のエンディングで散らばったパズルのピースを見つけることです。 したがって、4本の線に時間を割く必要はありません。爆発効果を見るために一本を切るだけで十分です。 第1関：活動ウェルカムエントリーページ 公式エントリーページに到着すると、画面中央の「今すぐ参加」ボタンは普通のジャンプボタンではなく、画像のホットスポットを通じて実現されています。手形の光標が見えたら、その位置を直接クリックすると次のエンディングに進みます。このエンディングは観察力を試し、HTML画像のホットスポット機能を少し使っています。 クリックすると、ページがまず黒くなり、次にロードが停止しているように見えるページにジャンプします。このブラックアウトはロード失敗ではなく、少し待つと問題が解決します。 第1.5関：ブラックアウト中のロード ページはほぼ完全に黒いです。複雑なソースコードを確認する必要はありません。ページのスクリーンショットを画像エディタに投入し、露出、影、コントラストを調整するだけで十分です。目的も明確で、画像の処理、露出の調整、低コントラスト情報の観察力を試すだけです。 明るくすると、2つの重要な情報が見えます： 開催コード：blog10years 次のエンディング：/level/googleLogin/login.html 第2関：ログインページ ログインページにはユーザー名、パスワード、招待コードが必要です。ユーザー名は自分で入力できますが、招待コードは前のエンディングで見つけた blog10years です。 本当に厄介なのはパスワードです。開発者ツールを開き、Consoleで buildLoginHash 処理が既に定義されていることを確認します。直接呼び出すだけでよいです： buildLoginHash("阿珏", "blog10years") ユーザー名が変更された場合は、処理内のユーザー名も変更してください。HMAC-SHA256文字列として返される処理をコピーし、パスワードとして使用します。パスワードを手動で計算する必要はありません。 ログイン前にキャプチャーを完了する必要があります。正しいを選択すると本当にログインできます。 このエンディングは、ソースコードを確認する習慣や開発者ツールの使用を試しています。パスワードは長い暗号化テキストのように見えますが、ページは生成方法を目の前で提供しています。 ps:阿珏酱が使ったアイコンはこの数年で何度も明かされてきました。 ...

ルール： マークダウン構造を保護する。 URLやコードを翻訳しない。 追加のコメントなしで翻訳された内容を返す。 # MoeKoe Music Mobile オープンソースでシンプルで高颜值のサードパーティーKuGou Musicのモバイル端末プレイヤー Expo / React Nativeに基づいて構築され、MoeKoeMusicデスクトップ版のモバイル版実装です 🌎 GitHubリポジトリ | 📦️ ダウンロードパッケージ | 💬 ブログアクセス | 🏠 プロジェクトホームページ オープンソースでシンプルで高颜值のサードパーティーKuGou Musicのモバイル端末プレイヤー Expo / React Nativeに基づいて構築され、MoeKoeMusicデスクトップ版のモバイル版実装です ✨ 特徴 🎵 サーバー自建不要 — KuGou APIのアダプテーションレイヤーが直接公式に直結し、すぐに使用可能で、外部APIアドレスに依存しません 🏠 ホームページの推薦 — 毎日の推薦、選定歌単、ランキング 🧭 発見ページ — カテゴリ別歌単、新曲速報などのコンテンツ探索 🔍 検索 — 歌曲や歌単、アルバムの迅速な検索 📀 歌単 / アルバム / ランキング — 完全な詳細ページと曲リスト 🎧 プレイヤー — ロールシャッター歌詞、プレイリスト、ミニプレイヤー（MiniPlayer）、バックグラウンドプレイ 🎚️ 音質検出 — 利用可能な音質を自動的に検出し、選択 📱 電話番号ログイン — KuGouアカウントの收藏と歌単の同期 🌗 ダークモード — システムに従って明暗テーマを自動的に切り替え 📝 Todoリスト [x] ホームページの毎日の推薦 / 選定歌単 / ランキング [x] 発見ページのカテゴリ別内容の閲覧 [x] 歌曲や歌単、アルバムの検索 [x] 歌単 / アルバム / ランキングの詳細ページ [x] プレイヤー：ロールシャッター歌詞、プレイリスト、ミニプレイヤー、バックグラウンドプレイ [x] 音質検出と自動選択 [x] 電話番号ログイン [x] 認証情報ログイン [x] スキャンログイン（他のデバイス） [x] いいね / 收藏の同期 [x] ユーザー歌単管理（作成 / 收藏 / 編集） [ ] 通知バー / ロックスクリーンプレイコントロール [ ] 歌曲詳細の閲覧 [ ] テキストから歌詞の検出 [ ] タブレットと横画面の対応 [ ] パフォーマンス最適化 📸 プレビュー 🚀 快速スタート 環境要件 Node.js ≥ 22 Git iOSシミュレータ / Androidシミュレータ、または開発版クライアントがインストールされた実際のデバイス 開発と実行 # リポジトリをクローン（api submoduleを含む） git clone --recurse-submodules https://github.com/MoeKoeMusic/MoeKoeMusic-Mobile.git cd MoeKoeMusic-Mobile # 依存関係をインストール npm install npm --prefix api install # モバイル端末APIエントリを生成（api/ 更新後は再実行が必要） npm run generate:mobile-api # 開発サーバーを起動 npx expo start クローン時にsubmoduleが欠けている場合は、git submodule update --initを実行して補完できます。 ...

ルール： Markdownの構造を保護する。 URLやコードは翻訳しない。 翻訳された内容のみを返す。 MoeKoe Music エクステンション MoeKoe Music ブラウザエクステンション版は、MoeKoeMusic Webをベースに構築され、ブラウザエクステンション内でAPIルートの互換性を完了しています。 🌎 GitHubリポジトリ 特徴 ブラウザエクステンションのアイコンをクリックして、独立したウィンドウでMoeKoeMusicを起動します。 ユーザーがAPIアドレスを設定する必要はなく、ローカルのAPIサービスを追加で起動する必要もありません。 MoeKoeMusicのオリジナルWebページとインタラクションを保持し、ブラウザエクステンションの運行環境に互換性があります。 快速スタート 環境要求 Node.js 20以降 Git Chrome / EdgeなどのChromiumコアブラウザ 依存関係のインストール git submodule update --init --recursive npm install npm run install:app npm run install:appは、MoeKoeMusicとMoeKoeMusic/apiの依存関係をそれぞれインストールします。インストール後は、子モジュールのワークスペースを確認し、アップストリームのlockfileの非期待の変更をコミットしないようにしてください。 エクステンションの構築 npm run build 構築物は以下に输出されます： dist/extension ブラウザにインストール chrome://extensionsまたはedge://extensionsを開きます。 「開発者モード」を有効にします。 「既に解凍されたエクステンションをロード」をクリックします。 プロジェクトのdist/extensionディレクトリを選択します。 extensionソースディレクトリをロードしないでください。そうすると、ブラウザはマニフェストやバックグラウンドスクリプトの読み込みに失敗を通知します。 APIの実行方法 MoeKoe Music Webバージョンに比べて、このプラグイン版はユーザーにAPIアドレスを入力させることはありません。MoeKoeMusicのフロントエンドは、HTTPルートに基づいてリクエストを送信し、ビルド時にAxiosリクエストをエクステンション内部のメッセージチャネルに適用します。 リクエストフローは以下の通りです： MoeKoeMusic Web -> extension/app/api-adapter.js -> extension/api/service-worker.cjs -> extension/api/generated/modules.cjs -> extension/api/generated/modules.cjs -> MoeKoeMusic/api/module/*.js -> 酷狗関連インターフェース extension/api/generated/modules.cjsは生成ファイルで、scripts/generate-extension-api-entry.mjsがMoeKoeMusic/api/moduleをスキャンして生成します。APIモジュールを追加または更新した場合、以下のいずれかの命令を再実行します： ...

ルール： マークダウン構造を保護。 URLやコードを翻訳しない。 追加のコメントなしで翻訳された内容を返す。 ルール： マークダウン構造を保護。 URLやコードを翻訳しない。 追加のコメントなしで翻訳された内容を返す。 ルール： マークダウン構造を保護。 URLやコードを翻訳しない。 追加のコメントなしで翻訳された内容を返す。 在做插件市场之前，先有的是 MoeKoe 的普通插件系统。 当時我想解决的问题不是某一个具体功能，而是一个更通用的问题：播放器里总会冒出很多小需求，有些人想改界面，有些人想加一个工具弹窗，有些人想接自己的服务。如果每个想法都往主程序里塞，主程序会越来越重，也越来越难维护。 所以我一开始给插件系统定的方向很明确：主程序只提供插件运行环境和管理入口，具体功能交给插件自己做。插件能独立安装、独立卸载，坏了也尽量不要影响播放器本体。 上一篇我写的是 MoeKoeMusic-Plugins 这个插件登记仓库。那边解决的是“插件市场的数据怎么产生”：用户用 Issue 提交，Action 校验，维护者审核，通过后写进 plugins.json。 但光有登记仓库还不够。真正对用户来说，插件市场不是 GitHub 上的一份 JSON，而是客户端里一个能看、能搜、能安装、能更新的入口。 所以这篇就换到 MoeKoe Music 主项目里，专门聊客户端的插件市场部分。 为什么选 Chrome Extension 这一套 MoeKoe は Electron アプリであり、Electron 自身に拡張の読み込み能力があります。既に Chrome Extension が動作する底層があるので、新しいプラグインフォーマットをゼロから設計する必要はありません。 この方法はいくつかの利点があります： 第一，プラグイン作者は完全に新しいフォーマットを学ぶ必要がありません。manifest.json、popup.html、background.js はすべてブラウザ拡張でよく使われる概念です。 第二，プラグインには天然のリストファイルがあります。主プログラムはまず manifest.json を読み取り、プラグイン名、バージョン、説明、権限、ポップアップエントリ、最低サポートバージョンなどの情報を判断します。 第三，Electron はプラグインディレクトリを直接読み込むことができます。私がサンドボックススクリプトを書く必要はありません。 展示、検索、分页と状態 プラグイン市場はインストールできるだけでなく、迅速に判断する必要があります： このプラグインは何をしていますか 私はこれをインストールしていますか 私がインストールしているのは旧バージョンですか このプラグインにはより高いバージョン要求がありますか それがネットワーク、ファイルアクセス、ローカルバイナリなどのリスクポイントを持っていますか 分页、検索、更新、状態 したがって、市場カードには「インストール」ボタンだけでなく表示されます。 プラグインディレクトリが存在することを確認 Electron を呼び出してダウンロード、インストール、旧バージョンをアンインストール、新しいバージョンをインストール プラグイン関連の IPC を登録 Chrome 拡張をロード Native Host インデックスと認証システムをロード 已安装插件 プラグイン管理ページの「已安装插件」は、現在読み込まれている Electron 拡張だけでなく、二つの情報を統合します： ...

ルール： マークダウン構造を保護する。 URLやコードを翻訳しない。 翻訳された内容のみを返す。 MoeKoe Music 插件エコシステムを最初に作成した時、オンラインプラグイン市場という機能はまだありませんでした 後にコミュニティの提案により、このプラグイン市場が誕生しました 公式/コミュニティプラグインリポジトリを追加して製品機能を拡張 プラグインはコミュニティで開発されるので、プラグイン市場はどう管理すべきか？ 最も直接的な方法は、すべてのプラグインソースコードを一つの大リポジトリにまとめることです。しかし、この案は考えれば考えるほど不自然に感じられました。それぞれのプラグインには、それぞれの作者、それぞれのリリースリズム、それぞれのビルド方法があります。これらをすべて公式リポジトリにまとめると、メンテナンスコストが高くなるだけでなく、責任範囲も曖昧になります。 したがって、このリポジトリは最終的には「プラグインソースコードリポジトリ」として設計されず、代わりに「プラグイン登録とインデックスリポジトリ」となりました。それは以下の数点を行います： プラグインの上架、更新、下架、および報告の申請を受け取る 基本的な検証と静的認識を自動的に行う 人工的に承認されたプラグインのスナップショットを記録する クライアントが読み込める plugins.json を維持する READMEにプラグインリストを更新する、人々が読みやすくする 追跡可能な登記簿：誰が提出したか、どのバージョンが承認されたか、ダウンロード先はどこか、ネットワークやファイルの権限はどうか、すべて明確なデータにまとめられます。 市場インデックス、ソースコードリポジトリではなく リポジトリのルートディレクトリで最も重要なファイルは plugins.json です。これがプラグイン市場が実際に消費するデータソースです。 { "id": "custom-app-background", "name": "カスタム背景画像", "description": "MoeKoe Musicにカスタム背景画像機能を提供し、透明度調節をサポート。", "iconUrl": "...", "version": "1.0.0", "minversion": "1.6.1", "...":"....", "buildRequired": false, "networkAccess": false, "fileAccess": false, "binaryContent": false, "snapshot": { "iconUrl": "...", "repository": "MoeKoeMusic/custom-app-background-plugin", "commitSha": "dbf72d38c8cf6b1d1cefdf8ce15798d565678995", "downloadUrl": "hxx.zip", "release": null } } 私は市場が「プラグインリポジトリの「現在の最新コード」を常に記録するようにしないことを望んでいます。なぜなら、作者が今日提出したコードと、承認当日に見たコードが同じものではなかったかもしれないからです。プラグイン市場が本当に認めるべきは、承認されたバージョンです。 したがって、このプロジェクトには以下の核心原則があります： 上架されるのは、動き回るリポジトリのアドレスではなく、既にロックされたスナップショットです。 コンパイル不要のプラグインの場合、スナップショットはデフォルトブランチの当時のcommitにロックされます。コンパイルが必要なプラグインの場合、スナップショットは対応するReleaseタグと发行附件にロックされます。これにより、実際に問題が発生した場合でも、当時どのバージョンが承認されたかを振り返ることができます。 アクションが先に動く、人間が最後に決定する ユーザーがIssueを提出する際には、以下の選択を行う必要があります： 「新規上架」または「プラグインの更新」 GitHubリポジトリのアドレス インストール前にコンパイルが必要かどうか Actionが自動検証を行い、結果をIssueのコメントに書き込むと同時に、check-passedまたはcheck-failedタグをIssueに付ける。 ...

続き：《同じアニメーション、3つの技術スタックで実装したらどう違うの？》 WebGL による二次元じゃんけんゲーム。 ルールは普通： グー > チョキ チョキ > パー パー > グー でも面白いのはここ： 負けると服を脱ぐ。 ええ、それだけです。単純かつストレート。 きっかけは「スプライトシートを研究したかった」 最初はゲームを作るつもりなんてなかった。 ただ研究したかっただけ： atlas sprite レイヤー合成 アニメーションカット こんな技術要素。 それで考えたんです：「実際に使える場面がないと？」 そして思い付き： じゃあ、二次元脱衣じゃんけんにすればいいと。 そしたらプロジェクトが暴走し始めた。 このプロジェクトで一番大変だったのはゲームロジックじゃない じゃんけんのルールはシンプルすぎる。 本当に大変だったのは：服のレイヤー管理 キャラクターは「1枚の完成した画像」ではなく： ベース画像 (全裸バレ防止のため、わざと暗号化済み) 服 A 服 B 服 C アクセサリー 遮蔽レイヤー 重ね続ける。 「脱衣」の正体はレイヤー管理 プレイヤーが勝った： 設定された順番で服を1枚除去 コンピュータが勝った： 逆順で服を着せる 聞こえるのは簡単。 実際は山のような問題にぶつかる： 例えば「ベース画像が一瞬見えてはいけない」 これは特に重要。 もしこうすると： 古い服を先に消す 新しい服を後で追加する その一瞬ベース画像がチラ見えする。 見た目がすごく変になる。 なので後で：reveal カバーロジックを使うことにした。 新しいレイヤーが即座に上に被さる。 極力避けたい： 「裸が1フレーム映り込む」 プロジェクト自体は不真面目に見えるけど 少なくとも技術的には美しくありたい。 WebGL はここで本当に心地いい このプロジェクトは最終的に WebGL で実装した。 理由はシンプル：レイヤーが多すぎる。 ...

最近、なかなか面白い小実験をやってみました。 二次元キャラクターのちょっとしたアニメーション効果を、それぞれ： WebGL Canvas 2D 純 DOM + CSS の3つの方法で実装し直しました。 効果自体は複雑ではありません： まばたき 眉毛/下まぶたの連動 汗のゆらゆらした揺れ アホ毛の振り動き でも本当に面白いのは、「作れた」こと自体ではなく： 同じものを、3つの技術スタックで実装したとき、どれくらい差が出るのか？ というところです。 本質的には「フロントエンドグラフィクス色の濃い」再現実験でした。 最初はただアホ毛アニメーションを再現したかった インスピレーション元：https://tamanidamani.itch.io/nijikas-ahoge 当時のシンプルな思い：「自分だったらどう実装する？」 そしてやるほどに熱中してしまい、最終的にこうなりました： じゃあ、WebGL、Canvas2D、DOM の3パターン全部作ってみよう。 そうしてリポジトリは今の形になりました： canvas/ canvas2D/ dom/ 同じ効果を3つのバージョンで実装しています。 まず結論 一言でまとめるなら： WebGL が最強だけど、Canvas2D が一番書きやすくて、DOM がビジネス向け 1. WebGL バージョン：「本当のゲーム開発」に一番近い このバージョンが一番手間がかかります。 なぜなら本質的には「フロントエンドアニメーション」ではなく：GPU グラフィクスプログラミング だからです。 どう実装しているのか？ コアとなる考え方は： 背景レイヤー1枚 スプライトを重ねていく shader で描画制御 JS でアニメーションパラメータを動かす 例えば： アホ毛の回転 まばたきの切り抜き alpha ブレンド これらはすべて GPU 側で処理されます。 だんだんとこういうものに触れるようになります： uniform texture shader UV 頂点座標 テクスチャ座標 そして笑顔が消えていきます。 でも WebGL は本当に強い 要素が増えてくると、WebGL の「全然平気」という感覚が際立ちます。 特に： ...

最近、コードを書くときに奇妙な感覚がある。 書けないわけでもなく、書きたくないわけでもない。 だが—— 自分の書くことがどんどん不要になっているような気がする。 かつては、機能を実装する際の流れはこうだった。 要件を理解する → 設計を考える → コードを書く → デバッグ → バグ修正 → リリース 今はどうなっている？ 要件を説明する → AIがコードを書く → AIがバグを直す → 確認するだけ → リリース その間にあった「コードを書く」という大きな部分が、突然薄くなり、ほぼ存在しなくなる。 最初はそれがすごく楽だった。 だが、楽しくなるにつれて少し不安になる。 かつてのプログラマーは、「タスクを完了する」ことで得られる達成感に加え、コードを書く過程そのものにも多くの喜びを感じていた。 コードを書くことって、もはや重要じゃない？ かつて私はプログラマーの最も核となる能力は「コードを書くこと」だと思っていた。 速さ、美しさ、抽象化の度合い——これらが「レベル」の差を作っていた。 だが、今ではこの基準がだんだん通用しなくなってきている。 多くのコードは、人間よりAIの方が早く、あるいは同じくらい良く書ける。 特に以下のようなもの： CRUD API連携 通常のロジック処理 AIは圧倒的な効率でこなしてしまう。 時々自分で書いたコードをAIに投げるようになる。 「ちょっと見直して」 すると、単に改善されただけでなく、自分が気づかなかったケースまで補ってくれる。 その瞬間、微妙な違和感がある—— このコード、誰が書いたのか区別できない。 さらに奇妙なのは、自分で書くのをやめてしまうこと これが本当に危険だ。 かつてはコードを書くことは「制御感」だった。 一行一行自分が打ったし、なぜそう書いたのか理解していたし、どこに問題があるかも把握していた。 だが、AIに任せることに慣れてくると、自分で書くことが逆に遅くなることに気づく。 そしてこう感じるようになる： 「なぜ自分で書かなきゃいけないのか？」 これは怠惰ではなく、効率の自然な選択だ。 大きな整数を手計算しないように、自動で生成できるコードを自分で書く必要もなくなる。 プログラマーは、別の役割へと変貌している だんだんと毎日の業務内容が変わってきていることに気づく。 もはや： どれだけコードを書くか どんなデザインパターンを使うか コードがきれいかどうか ではなく、 この要件は何をしたいのか？ AIにどう伝えると誤解されないか？ 結果は正しいか？ ということに時間を費やすようになる。 コードを書く時間よりも、むしろ—— 問題を明確にする時間がかかる。 ...

最近、個人ブログに「大改修」を施しました。 単一言語バージョンから多言語サイト（簡体字中国語、繁体字中国語、英語、日本語）にアップグレードし、 その全プロセスを自動化しました。💪 主な内容は以下の通りです。 メインサイトの記事を自動同期 コンテンツを自動AI翻訳 多言語サイトの自動構築とデプロイ なぜ Hugo を選んだのか？ それは、その自信に満ちたスローガンがあったからです。 “The world’s fastest framework for building websites.” —— この一言で、これに決めました 😆。 しかし、私は「一つのテーマで多言語を切り替える」という伝統的な方法ではなく、 各言語に独立したテーマを持たせることにしました。 これにより、各言語バージョンが独自のデザインとレイアウトスタイルを保持し、 真に「文化的なローカライゼーション」を実現できます。 設計目標と制約 🎯 言語: 簡体字中国語、繁体字中国語、英語、日本語をサポートし、将来的に拡張可能。 テーマ: 各言語に最適な Hugo テーマを使用し、無理に再利用しない。 コンテンツ同期: 全言語で一つのコンテンツリポジトリを共有し、必要に応じて翻訳。 デプロイ戦略: 各言語を独立して構築・公開し、異なるブランチやドメインにデプロイ可能。 カスタムページ: 「友だちリンク」、「書斎」、「アーカイブ」などのページは、多言語で一貫した体験を維持する。 多言語設定戦略 🧩 各言語用に個別の設定ファイルを用意しました。 config/<lang>.toml で、主に以下の役割を担います。 テーマの指定（例: theme = "PaperMod"）。 その言語固有の title / description / keywords の定義。 異なるテーマのナビゲーション構造に合わせるためのメニュー設定 [[params.menu]] の上書き。 全体的な視覚的一貫性を保証するためのカスタムスタイルの注入。 この構造は非常に明確で、将来的にさらに多くの言語バージョンを拡張するのにも便利です。 GitHub Actions 自動デプロイマトリックス ⚙️ CI/CD 部分は完全に GitHub Actions に任せています。 .github/workflows/hugo.yml では、マトリックスビルドを使用し、 各言語を独立して構築・公開しています。 ...

皆さんが使い倒したあのランダム画像APIを覚えていますか？本日、それがアップデートされました！過去数年間、ランダム画像APIは多くのフロントエンド開発者、二次元サイト運営者、さらにはデスクトッププラグイン愛好家にとっての「おもちゃ」であり「常用ツール」でした。 🥇 第一世代：シンプルだが扱いにくい出発点 当時のランダム画像APIは、正直なところ——単なるPHPスクリプトと1台のクラウドホストでした。当時の目標はシンプルでした：ランダムな画像を返すAPIを提供すること。 特徴は以下の通りです： すべてのリクエストが1台のサーバーに集中していました； 画像ストレージとAPIサービスが密結合していました； キャッシュなし、スマートな分散なし、単一ポイントのパフォーマンスに完全に依存していました； ピーク時にはCPUが急上昇し、502エラーが発生し、アクセスが遅く、トラフィックとストレージを消費していました； [クライアント] ---> [中央サーバー(唯一)] ---> [画像ファイル] 🥈 第二世代：クラウド化とキャッシュの過渡期 第二世代に入ると、ランダム画像APIは「クラウド化」の段階へと移行しました。サービスはクラウドへ移行し、キャッシュ、CDN、ロードバランシングが導入されました。 主な変更点： 画像は第三者の画像ホスティングサービス（例：新浪図床）に一元的にホストされました； APIはクラウドホストまたは軽量アプリケーションサーバー上で動作しました； 基本的なキャッシュロジック（例：RedisまたはNginxキャッシュ層）が追加されました； サービス全体がより安定し、アクセス速度も大幅に向上しました。 [クライアント] ↓ [クラウドサーバーAPI層] --> [CDN キャッシュ] --> [画像ホスティングサービス(Sina)] アクセスは依然として中央サーバーを経由する必要があり、高負荷時や地域ネットワークの分布が不均一な場合、遅延は依然として顕著でした。 すべてのリクエストはやはり「中央サーバー」を経由する必要があり、 一度サーバーがダウンすれば、全体が巻き添えを食らいました 💀。 🚀 第三世代ランダム画像APIが登場！ ✨ 主要なハイライト 第三世代ランダム画像APIは、アーキテクチャレベルでの再生です。 Tencent Cloud EdgeOneの3200以上のエッジノードの強力な能力に支えられ、リクエストはグローバルに自動的にスケジューリングされ、ユーザーに最も近いノードで実行されます。これにより、真の非中央集権型分散アーキテクチャが実現されました。 ⚡️ 主な変更点： 🌐 EdgeOneエッジノードネットワークに依存； 🧠 スマートなスケジューリング、近接応答； 🧱 エッジ関数をトリガーし、ノードで直接ロジックを実行； 📉 アクセス遅延が大幅に削減され、安定性と可用性が大幅に向上。 ┌────────┐ [クライアント] ──▶ │ 最も近いエッジノード │ └───┬─────┘ ↓ [エッジ関数がリクエストを処理] ↓ [ランダム画像リンクを応答] 🗂 システムアップデート ✅ 2.8万枚の画像を追加し、コンテンツがより豊富に； ✅ システムアーキテクチャを完全に再構築； ✅ 旧バージョンのアクセス制限を削除； ⚠️ 画像は引き続き新浪図床にホストされています（歴史的および周知の理由により）、一時的に中継アクセスを介しています。 📡 アクセス体験アドレス： 👉 https://random.moejue.cn 注：周知の理由により、グローバルアクセラレーションゾーン（中国大陸を除く）