package.json

npm 的 package.json 處理方式的具體事項

選擇 CLI 版本

說明

本文件說明您在 package.json 檔案中需要了解的所有事項。它必須是實際的 JSON，而不能只是 JavaScript 物件文字。

本文件中描述的許多行為會受到 config 中所述設定檔設定影響。

名稱

如果您打算發布套件，package.json 中最重要的欄位是 name 和 version，因為它們是必要的。name 和 version 一起形成一個識別碼，假設它完全唯一。套件的變更應與 version 的變更一起進行。如果您不打算發布套件，則 name 和 version 欄位是選用的。

name 是您的東西的名稱。

一些規則

name 必須小於或等於 214 個字元。這包括範圍套件的範圍。
範圍套件的名稱可以以點或底線開頭。沒有範圍時不允許這樣做。
新套件的名稱不能包含大寫字母。
name 最後會成為 URL 的一部分、命令列上的引數和資料夾名稱。因此，name 不能包含任何非 URL 安全字元。

一些提示

不要使用與核心 Node 模組相同的名稱。
不要在名稱中放入「js」或「node」。假設它是 js，因為您正在撰寫 package.json 檔案，而且您可以使用「engines」欄位指定引擎。（請參閱下方。）
name 可能會作為 require() 的引數傳遞，因此它應該是簡短的，但也要有合理的描述性。
您可能需要查看 npm 註冊中心，看看是否已經有相同名稱的東西，在您對它產生太大的依賴之前。 https://www.npmjs.com/

名稱可以選擇性地加上範圍前綴，例如 @myorg/mypackage。請參閱 scope 以取得更多詳細資訊。

版本

版本必須可由 node-semver 解析，而此版本與 npm 捆綁在一起作為相依性。(npm install semver 自行使用它。)

說明

在其中放置說明。它是一個字串。這有助於人們發現您的套件，因為它列在 npm search 中。

關鍵字

在其中放置關鍵字。它是一個字串陣列。這有助於人們發現您的套件，因為它列在 npm search 中。

首頁

專案首頁的 URL。

範例

"homepage": "https://github.com/owner/project#readme"

錯誤

專案問題追蹤器的 URL 和/或應回報問題的電子郵件地址。對於遇到套件問題的人來說，這些很有用。

它應該看起來像這樣

{
  "bugs": {
    "url": "https://github.com/owner/project/issues",
    "email": "project@hostname.com"
  }
}

您可以指定一個或兩個值。如果您只想提供 URL，您可以將「bugs」的值指定為一個簡單的字串，而不是物件。

如果提供了 URL，npm bugs 命令將會使用它。

人員欄位：作者、貢獻者

「作者」是一個人員。「貢獻者」是一個人員陣列。一個「人員」是一個物件，它有一個「name」欄位，並可以選擇「url」和「email」，如下所示

{
  "name": "Barney Rubble",
  "email": "b@rubble.com",
  "url": "http://barnyrubble.tumblr.com/"
}

或者，您可以將所有內容縮短成一個字串，而 npm 將為您解析它

{
  "author": "Barney Rubble <b@rubble.com> (http://barnyrubble.tumblr.com/)"
}

無論哪種方式，電子郵件和 url 都是可選的。

npm 也會設定一個頂層的「維護人員」欄位，其中包含你的 npm 使用者資訊。

資金

你可以指定一個包含 URL 的物件，提供有關如何協助資助你的套件開發的最新資訊，或是一個字串 URL，或這些的陣列

{
  "funding": {
    "type": "individual",
    "url": "http://example.com/donate"
  },

  "funding": {
    "type": "patreon",
    "url": "https://www.patreon.com/my-account"
  },

  "funding": "http://example.com/donate",

  "funding": [
    {
      "type": "individual",
      "url": "http://example.com/donate"
    },
    "http://example.com/donateAlso",
    {
      "type": "patreon",
      "url": "https://www.patreon.com/my-account"
    }
  ]
}

使用者可以使用 npm fund 子指令，列出其專案所有相依項目的 funding URL，包括直接和間接相依項目的。當提供專案名稱時，也可以使用捷徑來拜訪每個 funding url，例如：npm fund <projectname>（當有多個 URL 時，將會拜訪第一個）

檔案

選用的 files 欄位是一個檔案模式陣列，描述當你的套件安裝為相依項目的時候要包含的項目。檔案模式遵循與 .gitignore 類似的語法，但相反：包含一個檔案、目錄或 glob 模式（*、**/* 等），會讓該檔案在打包時包含在 tarball 中。省略該欄位會讓它預設為 ["*"]，表示它會包含所有檔案。

一些特殊檔案和目錄也會包含或排除，無論它們是否存在於 files 陣列中（請見下方）。

你也可以在你的套件根目錄或子目錄中提供一個 .npmignore 檔案，這會讓檔案不會被包含。在你的套件根目錄中，它不會覆寫「files」欄位，但在子目錄中會。 .npmignore 檔案的工作方式就像 .gitignore。如果有一個 .gitignore 檔案，而 .npmignore 不存在，則會使用 .gitignore 的內容。

某些檔案會永遠包含，不論設定為何

package.json
README
LICENSE / LICENCE
「main」欄位中的檔案
「bin」欄位中的檔案

README 和 LICENSE 可以使用任何大小寫和副檔名。

預設情況下，某些檔案會永遠被忽略

*.orig
.*.swp
.DS_Store
._*
.git
.hg
.lock-wscript
.npmrc
.svn
.wafpickle-N
CVS
config.gypi
node_modules
npm-debug.log
package-lock.json（如果你希望發布，請使用 npm-shrinkwrap.json）
pnpm-lock.yaml
yarn.lock

這些忽略的檔案大部分都可以包含在 files globs 中。例外如下：

.git
.npmrc
node_modules
package-lock.json
pnpm-lock.yaml
yarn.lock

這些不能包含。

主程式

main 欄位是程式主要進入點的模組 ID。也就是說，如果你的套件名稱為 foo，使用者安裝後執行 require("foo")，則會傳回你的主模組的 exports 物件。

這應該是相對於套件資料夾根目錄的模組。

對大多數模組來說，最合理的做法是只有一個主腳本，而且通常不需要其他東西。

如果未設定 main，則會預設為套件根目錄中的 index.js。

瀏覽器

如果你的模組是供客戶端使用的，則應使用 browser 欄位，而非 main 欄位。這有助於提示使用者，模組可能依賴於 Node.js 模組中不存在的基本功能。（例如 window）

bin

許多套件都有希望安裝到 PATH 中的一個或多個可執行檔案。npm 讓這變得非常容易（事實上，它使用此功能來安裝「npm」可執行檔）。

要使用此功能，請在 package.json 中提供一個 bin 欄位，其中包含指令名稱對應至本機檔案名稱的對應。當這個套件是全域安裝時，該檔案將連結到全域 bins 目錄中，或將建立一個 cmd（Windows 指令檔），在 bin 欄位中執行指定檔案，因此可以使用 name 或 name.cmd（在 Windows PowerShell 中）執行。當這個套件作為另一個套件的相依套件安裝時，檔案將連結到套件可以直接透過 npm exec 使用，或在透過 npm run-script 呼叫其他腳本時，在名稱中使用。

例如，myapp 可以這樣做：

{
  "bin": {
    "myapp": "./cli.js"
  }
}

因此，當你安裝 myapp 時，在類 Unix 作業系統中，它會從 cli.js 腳本建立一個符號連結到 /usr/local/bin/myapp，在 Windows 中，它會建立一個 cmd 檔案，通常位於 C:\Users\{Username}\AppData\Roaming\npm\myapp.cmd，用於執行 cli.js 腳本。

如果你有一個可執行檔，而且它的名稱應該是套件的名稱，那麼你可以將它作為字串提供。例如：

{
  "name": "my-program",
  "version": "1.2.5",
  "bin": "./path/to/program"
}

等同於：

{
  "name": "my-program",
  "version": "1.2.5",
  "bin": {
    "my-program": "./path/to/program"
  }
}

請確定在 bin 中所引用的檔案以 #!/usr/bin/env node 開頭，否則腳本將在沒有 node 可執行檔的情況下啟動！

請注意，您也可以使用 directories.bin 設定可執行檔。

請參閱 folders 以取得有關可執行檔的更多資訊。

man

指定單一檔案或檔案名稱陣列，以供 man 程式尋找。

如果只提供單一檔案，則會安裝該檔案，使其成為 man <pkgname> 的結果，而與其實際檔案名稱無關。例如

{
  "name": "foo",
  "version": "1.2.3",
  "description": "A packaged foo fooer for fooing foos",
  "main": "foo.js",
  "man": "./man/doc.1"
}

會連結 ./man/doc.1 檔案，使其成為 man foo 的目標

如果檔案名稱未以套件名稱開頭，則會加上前綴。因此，此

{
  "name": "foo",
  "version": "1.2.3",
  "description": "A packaged foo fooer for fooing foos",
  "main": "foo.js",
  "man": ["./man/foo.1", "./man/bar.1"]
}

將建立檔案以執行 man foo 和 man foo-bar。

手冊檔案必須以數字結尾，如果已壓縮，則可以選擇加上 .gz 字尾。數字決定檔案安裝到的手冊區段。

{
  "name": "foo",
  "version": "1.2.3",
  "description": "A packaged foo fooer for fooing foos",
  "main": "foo.js",
  "man": ["./man/foo.1", "./man/foo.2"]
}

將建立 man foo 和 man 2 foo 的項目

儲存庫

指定您的程式碼所在的位置。這對想要貢獻的人有幫助。如果 git 存放庫在 GitHub 上，則 npm docs 指令將能夠找到您。

像這樣做

{
  "repository": {
    "type": "git",
    "url": "https://github.com/npm/cli.git"
  }
}

URL 應為可公開取得（可能為唯讀）的 URL，可直接傳遞給 VCS 程式，無需任何修改。它不應是您在瀏覽器中輸入的 HTML 專案頁面 URL。它是給電腦用的。

對於 GitHub、GitHub gist、Bitbucket 或 GitLab 儲存庫，您可以使用與 npm install 相同的捷徑語法

{
  "repository": "npm/npm",

  "repository": "github:user/repo",

  "repository": "gist:11081aaa281",

  "repository": "bitbucket:user/repo",

  "repository": "gitlab:user/repo"
}

如果封裝的 package.json 不在根目錄（例如，它是單一儲存庫的一部分），您可以指定它所在的目錄

{
  "repository": {
    "type": "git",
    "url": "https://github.com/facebook/react.git",
    "directory": "packages/react-dom"
  }
}

指令碼

「指令碼」屬性是一個字典，其中包含在封裝生命週期中不同時間執行的指令碼命令。金鑰是生命週期事件，而值是在該時間點執行的命令。

請參閱 scripts 以進一步了解如何撰寫封裝指令碼。

設定

「設定檔」物件可設定封裝指令碼中使用的設定檔參數，這些參數會在升級過程中持續存在。例如，如果封裝具有以下內容

{
  "name": "foo",
  "config": {
    "port": "8080"
  }
}

它也可以有一個「開始」命令，該命令會參照 npm_package_config_port 環境變數。

相依性

相依性會以一個簡單的物件指定，該物件會將封裝名稱對應到版本範圍。版本範圍是一個字串，其中包含一個或多個以空白分隔的描述符。相依性也可以透過 tarball 或 git URL 來識別。

請勿將測試架構、轉譯器或其他「開發」時間工具放入 dependencies 物件中。請參閱下方的 devDependencies。

請參閱 semver 以進一步了解如何指定版本範圍。

version 必須與 version 完全相符
>version 必須大於 version
>=version 等
<version
<=version
~version 「大約等於版本」請參閱 semver
^version 「與版本相容」請參閱 semver
1.2.x 1.2.0、1.2.1 等，但不包括 1.3.0
http://... 請參閱下方的「URL 作為相依性」
* 符合任何版本
"" (僅為空字串) 與 * 相同
version1 - version2 與 >=version1 <=version2 相同。
range1 || range2 如果 range1 或 range2 其中一項符合，則通過。
git... 請參閱下方的「Git URL 做為相依性」
user/repo 請參閱下方的「GitHub URL」
tag 以 tag 標記並發布的特定版本。請參閱 npm dist-tag
path/path/path 請參閱下方的本地路徑

例如，以下皆為有效

{
  "dependencies": {
    "foo": "1.0.0 - 2.9999.9999",
    "bar": ">=1.0.2 <2.1.2",
    "baz": ">1.0.2 <=2.3.4",
    "boo": "2.0.1",
    "qux": "<1.0.0 || >=2.3.1 <2.4.5 || >=2.5.2 <3.0.0",
    "asd": "http://asdf.com/asdf.tar.gz",
    "til": "~1.2",
    "elf": "~1.2.3",
    "two": "2.x",
    "thr": "3.3.x",
    "lat": "latest",
    "dyl": "file:../dyl"
  }
}

URL 作為相依性

您可以指定 tarball URL 來取代版本範圍。

此 tarball 將會在安裝時下載並安裝到您的套件中。

Git URL 作為相依性

Git URL 的格式為

<protocol>://[<user>[:<password>]@]<hostname>[:<port>][:][/]<path>[#<commit-ish> | #semver:<semver>]

<protocol> 為 git、git+ssh、git+http、git+https 或 git+file 之一。

如果提供 #<commit-ish>，將會用來複製該提交。如果提交有 #semver:<semver> 格式，<semver> 可以是任何有效的 semver 範圍或精確版本，而 npm 會在遠端儲存庫中尋找與該範圍相符的任何標記或參照，就像處理登錄相依性一樣。如果未指定 #<commit-ish> 或 #semver:<semver>，則會使用預設分支。

範例

git+ssh://git@github.com:npm/cli.git#v1.0.27
git+ssh://git@github.com:npm/cli#semver:^5.0
git+https://isaacs@github.com/npm/cli.git
git://github.com/npm/cli.git#v1.0.27

從 git 儲存庫安裝時，package.json 中的特定欄位存在會導致 npm 認為需要執行建置。為此，您的儲存庫會複製到暫存目錄中，安裝其所有相依性、執行相關指令，並封裝並安裝產生的目錄。

如果您的 git 相依性使用 工作區，或存在以下任何指令，就會發生此流程

build
準備
預先封裝
預先安裝
安裝
安裝後

如果你的 Git 儲存庫包含預先建置的成品，你可能會希望確保上述腳本都沒有定義，否則你的相依項會在每次安裝時重新建置。

GitHub URL

從 1.1.65 版開始，你可以將 GitHub URL 僅視為「foo」：「user/foo-project」。與 Git URL 一樣，可以包含 commit-ish 字尾。例如

{
  "name": "foo",
  "version": "0.0.0",
  "dependencies": {
    "express": "expressjs/express",
    "mocha": "mochajs/mocha#4727d357ea",
    "module": "user/repo#feature/branch"
  }
}

本機路徑

從 2.0.0 版開始，你可以提供包含套件的本機目錄路徑。可以使用 npm install -S 或 npm install --save，使用下列任何一種格式來儲存本機路徑

../foo/bar
~/foo/bar
./foo/bar
/foo/bar

這種情況下，它們會正規化為相對路徑，並加入你的 package.json。例如

{
  "name": "baz",
  "dependencies": {
    "bar": "file:../foo/bar"
  }
}

此功能有助於本機離線開發和建立需要 npm 安裝的測試，在這種情況下，你不需要連線外部伺服器，但不要在將套件發布到公開註冊表時使用。

注意：在此情況下，透過本機路徑連結的套件不會在執行 npm install 時安裝它們自己的相依項。你必須從本機路徑內部執行 npm install。

devDependencies

如果有人計畫下載並在他們的程式中使用你的模組，那麼他們可能不想要或不需要下載並建置你使用的外部測試或文件架構。

在這種情況下，最好在 devDependencies 物件中對應這些額外的項目。

在從套件根目錄執行 npm link 或 npm install 時，這些項目會安裝，並且可以像任何其他 npm 設定參數一樣管理。請參閱 config 以進一步了解此主題。

對於非特定於平台的建置步驟，例如將 CoffeeScript 或其他語言編譯成 JavaScript，請使用 prepare 腳本來執行此操作，並將所需的套件設為 devDependency。

例如

{
  "name": "ethopia-waza",
  "description": "a delightfully fruity coffee varietal",
  "version": "1.2.3",
  "devDependencies": {
    "coffee-script": "~1.6.3"
  },
  "scripts": {
    "prepare": "coffee -o lib/ -c src/waza.coffee"
  },
  "main": "lib/waza.js"
}

在發布之前會執行 prepare 腳本，這樣使用者就能使用此功能，而不需要自行編譯。在開發模式（例如，在本地執行 npm install）中，它也會執行此腳本，讓您可以輕鬆地測試它。

peerDependencies

在某些情況下，您希望表達您的套件與主機工具或函式庫的相容性，而不需要對此主機進行 require。這通常稱為外掛程式。特別是，您的模組可能會公開一個特定介面，這是主機文件預期和指定的。

例如

{
  "name": "tea-latte",
  "version": "1.3.5",
  "peerDependencies": {
    "tea": "2.x"
  }
}

這可確保您的套件 tea-latte 可以與主機套件 tea 的第二個主要版本一起安裝。 npm install tea-latte 可能會產生以下依賴關係圖

├── tea-latte@1.3.5
└── tea@2.2.0

在 npm 版本 3 到 6 中， peerDependencies 不會自動安裝，如果在樹中找到無效版本的對等依賴項，它會發出警告。從 npm v7 開始，對等依賴項會預設安裝。

如果樹無法正確解析，嘗試安裝具有衝突需求的另一個外掛程式可能會導致錯誤。因此，請確保您的外掛程式需求盡可能廣泛，並且不要將其鎖定到特定的修補程式版本。

假設主機符合 semver，只有主機套件主要版本的變更才會中斷您的外掛程式。因此，如果您已使用主機套件的每個 1.x 版本，請使用 "^1.0" 或 "1.x" 來表達這一點。如果您依賴於 1.5.2 中引入的功能，請使用 "^1.5.2"。

peerDependenciesMeta

當使用者安裝您的套件時，如果 peerDependencies 中指定的套件尚未安裝，npm 會發出警告。 peerDependenciesMeta 欄位用於向 npm 提供有關如何使用您的對等依賴項的更多資訊。具體來說，它允許將對等依賴項標記為選用。

例如

{
  "name": "tea-latte",
  "version": "1.3.5",
  "peerDependencies": {
    "tea": "2.x",
    "soy-milk": "1.2"
  },
  "peerDependenciesMeta": {
    "soy-milk": {
      "optional": true
    }
  }
}

將對等依賴項標記為選用可確保如果主機上未安裝 soy-milk 套件，npm 不會發出警告。這允許您整合和與各種主機套件互動，而不需要安裝所有這些套件。

bundleDependencies

這定義了一個套件名稱陣列，這些名稱將在發布套件時進行綑綁。

在需要在本地保留 npm 套件或透過單一檔案下載取得套件的情況下，你可以透過在 bundleDependencies 陣列中指定套件名稱，並執行 npm pack 來將套件打包成 tarball 檔案。

例如

如果我們定義一個像這樣的 package.json

{
  "name": "awesome-web-framework",
  "version": "1.0.0",
  "bundleDependencies": ["renderized", "super-streams"]
}

我們可以透過執行 npm pack 來取得 awesome-web-framework-1.0.0.tgz 檔案。此檔案包含相依性 renderized 和 super-streams，它們可以透過執行 npm install awesome-web-framework-1.0.0.tgz 在新的專案中安裝。請注意，套件名稱不包含任何版本，因為該資訊已在 dependencies 中指定。

如果這拼寫為 "bundledDependencies"，那也會受到尊重。

或者，"bundleDependencies" 可以定義為布林值。值為 true 將會打包所有相依性，值為 false 將不會打包任何相依性。

optionalDependencies

如果可以使用的相依性，但你希望 npm 在找不到或無法安裝時繼續進行，則可以將其放入 optionalDependencies 物件中。這是一個套件名稱對應版本或 URL 的對應，就像 dependencies 物件一樣。不同的是，建置失敗不會導致安裝失敗。執行 npm install --omit=optional 將會防止安裝這些相依性。

處理相依性不足仍然是你的程式責任。例如，像這樣的東西

try {
  var foo = require("foo");
  var fooVersion = require("foo/package.json").version;
} catch (er) {
  foo = null;
}
if (notGoodFooVersion(fooVersion)) {
  foo = null;
}

// .. then later in your program ..

if (foo) {
  foo.doFooThings();
}

optionalDependencies 中的項目將會覆寫 dependencies 中同名的項目，因此通常最好只放在一個地方。

overrides

如果你需要對相依性的相依性進行特定變更，例如用已知安全問題的相依性版本取代、用分支取代現有的相依性，或確保在所有地方都使用相同版本的套件，則可以新增一個覆寫。

覆寫提供了一種方式，可以用另一個版本或另一個套件完全取代相依性樹中的套件。這些變更可以設定為特定範圍或模糊範圍，具體取決於需要。

為了確保套件 foo 不論相依性依賴哪個版本，都始終安裝為版本 1.0.0

{
  "overrides": {
    "foo": "1.0.0"
  }
}

以上為簡寫符號，完整的物件形式可用於允許覆寫套件本身以及套件的子項目。這將導致 foo 永遠為 1.0.0，同時也讓 bar 在 foo 之後的所有深度都為 1.0.0

{
  "overrides": {
    "foo": {
      ".": "1.0.0",
      "bar": "1.0.0"
    }
  }
}

僅在 foo 為套件 bar 的子項目（或孫項目、曾孫項目等）時，才將 foo 覆寫為 1.0.0

{
  "overrides": {
    "bar": {
      "foo": "1.0.0"
    }
  }
}

金鑰可以巢狀到任何任意長度。僅在 foo 為 bar 的子項目，且僅在 bar 為 baz 的子項目時，才覆寫 foo

{
  "overrides": {
    "baz": {
      "bar": {
        "foo": "1.0.0"
      }
    }
  }
}

覆寫的金鑰也可以包含版本或版本範圍。將 foo 覆寫為 1.0.0，但僅在 foo 為 bar@2.0.0 的子項目時

{
  "overrides": {
    "bar@2.0.0": {
      "foo": "1.0.0"
    }
  }
}

您不得設定直接依賴套件的覆寫，除非依賴項和覆寫本身共用完全相同的規格。為了讓此限制更易於處理，覆寫也可以定義為直接依賴項規格的參考，方法是在您希望版本相符的套件名稱之前加上 $。

{
  "dependencies": {
    "foo": "^1.0.0"
  },
  "overrides": {
    // BAD, will throw an EOVERRIDE error
    // "foo": "^2.0.0"
    // GOOD, specs match so override is allowed
    // "foo": "^1.0.0"
    // BEST, the override is defined as a reference to the dependency
    "foo": "$foo",
    // the referenced package does not need to match the overridden one
    "bar": "$foo"
  }
}

engines

您可以指定您的東西在什麼版本的 node 上運作

{
  "engines": {
    "node": ">=0.10.3 <15"
  }
}

而且，就像依賴項一樣，如果您未指定版本（或將版本指定為 "*"），則任何版本的 node 都可以。

您也可以使用「engines」欄位來指定哪些版本的 npm 能夠正確安裝您的程式。例如

{
  "engines": {
    "npm": "~1.0.20"
  }
}

除非使用者已設定 engine-strict 組態旗標，此欄位僅供建議，且僅在您的套件安裝為依賴項時才會產生警告。

os

您可以指定您的模組將在哪些作業系統上執行

{
  "os": ["darwin", "linux"]
}

您也可以封鎖作業系統，而不是允許作業系統，只要在被封鎖的作業系統之前加上「!」即可

{
  "os": ["!win32"]
}

主機作業系統由 process.platform 決定

允許同時封鎖和允許項目，儘管這麼做沒有任何好理由。

cpu

如果你的程式碼只在特定 CPU 架構上執行，你可以指定哪些架構。

{
  "cpu": ["x64", "ia32"]
}

就像 os 選項，你也可以封鎖架構

{
  "cpu": ["!arm", "!mips"]
}

主機架構由 process.arch 決定

在以下範例中，只要 ./packages 資料夾內的所有資料夾在其內部有有效的 package.json 檔案，它們都將被視為工作區

{
  "name": "workspace-example",
  "workspaces": ["./packages/*"]
}

請參閱 workspaces 以取得更多範例。

預設值

npm 將根據套件內容預設一些值。

"scripts": {"start": "node server.js"}

如果你的套件根目錄中有一個 server.js 檔案，npm 將預設 start 指令為 node server.js。
"scripts":{"install": "node-gyp rebuild"}

如果你的套件根目錄中有一個 binding.gyp 檔案，而且你沒有定義 install 或 preinstall 指令，npm 將預設 install 指令使用 node-gyp 編譯。
"contributors": [...]

如果您的套件根目錄中有 AUTHORS 檔案，npm 會將每一行視為 姓名 <電子郵件> (網址) 格式，其中電子郵件和網址為選用。以 # 開頭或空白的行將會被忽略。

另請參閱

在 GitHub 上編輯此頁面

12 contributors

最後由 s100 於 2024 年 4 月 11 日編輯