package.json

npm 处理 package.json 的具体细节

选择 CLI 版本

描述

本文档是您需要了解的关于 package.json 文件中所需内容的所有内容。它必须是实际的 JSON，而不仅仅是 JavaScript 对象文字。

本文档中描述的大部分行为都受到 config 中描述的配置设置的影响。

name

如果您打算发布您的包，package.json 中最重要的内容是 name 和 version 字段，因为它们是必需的。name 和 version 一起构成一个被认为是完全唯一的标识符。对包的更改应该伴随着对版本的更改。如果您不打算发布您的包，name 和 version 字段是可选的。

name 是您要命名的事物。

一些规则

name 的字符数必须小于或等于 214 个。这包括作用域包的作用域。
作用域包的名称可以以点或下划线开头。未加作用域时，不允许这样做。
新的包的名称中不能包含大写字母。
name 最终会成为 URL 的一部分、命令行上的参数以及文件夹名称。因此，name 不能包含任何非 URL 安全字符。

一些提示

不要使用与核心 Node 模块相同的名称。
不要在名称中包含“js”或“node”。由于您正在编写 package.json 文件，因此默认情况下它会被认为是 js，并且可以使用“engines”字段指定引擎。（见下文）
name 可能会作为参数传递给 require()，因此它应该简洁，但也要具有一定的描述性。
在您过于依赖它之前，您可能需要检查 npm 注册表以查看是否已经存在相同名称的包。https://npmjs.net.cn/

name 可以选择性地以作用域为前缀，例如 @myorg/mypackage。有关更多详细信息，请参阅 scope。

version

Version 必须能够被 node-semver 解析，该库与 npm 捆绑在一起作为依赖项。（npm install semver 可自行使用它。）

description

在其中添加描述。它是一个字符串。这有助于人们在 npm search 中列出您的包时发现它。

keywords

在其中添加关键字。它是一个字符串数组。这有助于人们在 npm search 中列出您的包时发现它。

homepage

项目主页的 URL。

示例

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

bugs

项目问题跟踪器的 URL 和/或应报告问题的电子邮件地址。这对遇到您包问题的人员很有帮助。

它应该像这样

{
  "bugs": {
    "url": "https://github.com/owner/project/issues",
    "email": "[email protected]"
  }
}

您可以指定其中一个值或两个值。如果您只想提供 URL，可以将“bugs”的值指定为简单字符串，而不是对象。

如果提供 URL，npm bugs 命令将使用它。

人员字段：author、contributors

“author” 是一个人。“contributors” 是一个人员数组。“person” 是一个包含“name” 字段的对象，可选地包含“url” 和“email”，如下所示

{
  "name": "Barney Rubble",
  "email": "[email protected]",
  "url": "http://barnyrubble.tumblr.com/"
}

或者你可以将所有这些缩短为一个字符串，npm 会为你解析它

{
  "author": "Barney Rubble <[email protected]> (http://barnyrubble.tumblr.com/)"
}

无论哪种方式，电子邮件和 URL 都是可选的。

npm 还会设置一个顶级的“maintainers”字段，其中包含你的 npm 用户信息。

funding

你可以指定一个对象，其中包含一个 URL，该 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。当提供项目名称时，还可以使用快捷方式访问每个资助 URL：npm fund <projectname>（当有多个 URL 时，将访问第一个 URL）

files

可选的 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 glob 中来明确包含。对此的例外是

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

这些不能包含。

main

main 字段是一个模块 ID，它是程序的主要入口点。也就是说，如果你的包名为 foo，用户安装了它，然后执行了 require("foo")，那么你的主模块的导出对象将被返回。

这应该是相对于你的包文件夹的根目录的模块。

对于大多数模块，拥有一个主脚本并且通常没有太多其他内容是最有意义的。

如果 main 未设置，它将默认为包根文件夹中的 index.js。

browser

如果你的模块打算在浏览器端使用，则应使用浏览器字段而不是主字段。这有助于提示用户它可能依赖于 Node.js 模块中不可用的基本类型。（例如 window）

bin

许多包有一个或多个可执行文件，它们希望安装到 PATH 中。npm 使这变得非常容易（实际上，它使用此功能来安装“npm”可执行文件。）

要使用它，请在你的 package.json 中提供一个 bin 字段，它是一个命令名称到本地文件名映射。当此包全局安装时，该文件将链接到全局 bin 目录中，或者将创建一个 cmd（Windows 命令文件），该文件将在 bin 字段中执行指定的文件，使其可通过 name 或 name.cmd（在 Windows PowerShell 上）运行。当此包作为另一个包的依赖项安装时，该文件将链接到它将可用于该包的地方，无论是直接通过 npm exec 还是通过名称在其他脚本中通过 npm run-script 调用它们。

例如，myapp 可以有这个

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

因此，当你在 Unix 类操作系统中安装 myapp 时，它将创建一个从 cli.js 脚本到 /usr/local/bin/myapp 的符号链接，在 Windows 中，它将创建一个通常位于 C:\Users\{Username}\AppData\Roaming\npm\myapp.cmd 的 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 设置可执行文件。

有关可执行文件的更多信息，请参阅文件夹。

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。

Man 文件必须以数字结尾，并可选地以 .gz 后缀结尾，如果它们被压缩。数字决定文件被安装到哪个 man 部分。

{
  "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 的条目

directories

CommonJS Packages 规范详细介绍了几种可以使用 directories 对象来指示你的包结构的方式。如果你看一下 npm 的 package.json，你会发现它有 doc、lib 和 man 的目录。

将来，这些信息可能会以其他创造性的方式使用。

directories.bin

如果你在 directories.bin 中指定了一个 bin 目录，那么该文件夹中的所有文件都将被添加。

由于 bin 指令的工作方式，指定 bin 路径和设置 directories.bin 是一个错误。如果你想指定单个文件，请使用 bin，对于现有 bin 目录中的所有文件，请使用 directories.bin。

directories.man

一个充满 man 页面的文件夹。使用糖来通过遍历文件夹生成一个“man”数组。

repository

指定你的代码所在的位置。这对想要做出贡献的人很有帮助。如果 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 不在根目录中（例如，如果它是 monorepo 的一部分），你可以指定它所在的目录

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

scripts

“scripts”属性是一个字典，其中包含在你的包的生命周期中不同时间运行的脚本命令。键是生命周期事件，值是该事件运行的命令。

有关编写包脚本的更多信息，请参阅 scripts。

config

可以使用“config”对象来设置包脚本中使用的配置参数，这些参数在升级过程中会一直存在。例如，如果一个包有以下内容

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

它还可以有一个“start”命令，该命令引用 npm_package_config_port 环境变量。

dependencies

依赖项在简单对象中指定，该对象将包名称映射到版本范围。版本范围是一个字符串，其中包含一个或多个空格分隔的描述符。依赖项也可以用 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>，它将用于精确克隆该提交。如果 commit-ish 的格式为 #semver:<semver>，<semver> 可以是任何有效的 semver 范围或精确版本，npm 会在远程仓库中查找与该范围匹配的任何标签或引用，就像查找注册表依赖项一样。如果未指定 #<commit-ish> 或 #semver:<semver>，则使用默认分支。

示例

git+ssh://[email protected]:npm/cli.git#v1.0.27
git+ssh://[email protected]:npm/cli#semver:^5.0
git+https://[email protected]/npm/cli.git
git://github.com/npm/cli.git#v1.0.27

从 git 仓库安装时，package.json 中某些字段的存在会导致 npm 认为需要执行构建。为此，您的仓库将被克隆到一个临时目录中，安装其所有依赖项，运行相关脚本，并将结果目录打包并安装。

如果您的 git 依赖项使用 workspaces，或者存在以下任何脚本，则将发生此流程

build
prepare
prepack
preinstall
install
postinstall

如果您的 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 可能产生以下依赖项图

├── [email protected]
└── [email protected]

在 npm 3 到 6 版本中，peerDependencies 不会自动安装，如果在树中发现无效的 peer 依赖项版本，则会发出警告。从 npm v7 开始，peerDependencies 默认情况下会安装。

尝试安装具有冲突要求的另一个插件可能会导致错误，如果无法正确解析树。出于这个原因，请确保您的插件要求尽可能广泛，不要将其锁定到特定的补丁版本。

假设主机符合 semver，只有主机包的主要版本中的更改才会破坏您的插件。因此，如果您使用过主机包的所有 1.x 版本，请使用 "^1.0" 或 "1.x" 来表示这一点。如果您依赖 1.5.2 中引入的功能，请使用 "^1.5.2"。

peerDependenciesMeta

当用户安装您的包时，如果 peerDependencies 中指定的包尚未安装，npm 会发出警告。 peerDependenciesMeta 字段用于为 npm 提供有关如何使用 peer 依赖项的更多信息。具体来说，它允许将 peer 依赖项标记为可选。

例如

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

将 peer 依赖项标记为可选可以确保 npm 不会在主机上未安装 soy-milk 包时发出警告。这使您可以与各种主机包集成并进行交互，而无需要求安装所有这些包。

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

如果您需要对依赖项的依赖项进行特定更改，例如用已知安全问题的版本的依赖项替换，用 fork 替换现有依赖项，或确保在所有地方使用同一个版本的包，那么您可以添加一个覆盖。

覆盖提供了一种用另一个版本或完全不同的包替换依赖项树中的包的方法。这些更改可以根据需要进行范围界定，具体或模糊均可。

为了确保包 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 的子级（或孙级、曾孙级等）时，才将其覆盖为 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，但仅当它是 [email protected] 的子级时

{
  "overrides": {
    "[email protected]": {
      "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 会将每行视为 Name <email> (url) 格式，其中 email 和 url 是可选的。以 # 开头或为空的行将被忽略。

另请参阅

在 GitHub 上编辑此页面

12 contributors

最后编辑者 s100 于 2024 年 4 月 11 日