GitHub MCP Server 作用域过滤Scope Filtering原理与实战指南PAT、OAuth 与工具可见性控制【免费下载链接】github-mcp-serverGitHubs official MCP Server项目地址: https://gitcode.com/GitHub_Trending/gi/github-mcp-serverGitHub 官方 MCP Servergithub-mcp-server提供了一套基于认证令牌 OAuth 作用域的自动化工具过滤机制当你使用 classic PAT 启动服务时服务器会主动探测令牌携带的作用域并隐藏那些当前令牌无权调用的工具从而减少工具列表噪音、提前规避“权限不足”类错误。本文以 docs/scope-filtering.md 为主体结合仓库源码pkg/scopes、pkg/http/middleware、pkg/inventory 等逐层拆解其工作原理、配置方法、scope 层级推导规则、OAuth 场景挑战机制与常见故障排查帮助你在本地与远程部署中精确控制 MCP 工具面。概述什么是 PAT 作用域过滤GitHub MCP Server 会根据你提供的classic Personal Access TokenPAT以ghp_开头的传统令牌的 OAuth 作用域自动过滤可供使用的 MCP 工具。这样做的目的有两个减少噪音只展示当前令牌真正有权调用的工具避免工具列表中出现大量注定失败的选项预防错误提前隐藏需要不可用作用域的工具从源头避免“调用时报 403/Insufficient permissions”的尴尬。该功能有明确的前提边界仅适用于 classic PAT。Fine-grained PAT、GitHub App 安装令牌ghs_开头以及 server-to-server 令牌不支持作用域探测服务会展示全部工具。工作原理一次轻量 HEAD 请求探测令牌作用域从 pkg/scopes/fetcher.go 的实现可以看到完整链路当服务以 classic PAT 启动后pkg/http/middleware/pat_scope.go 中的WithPATScopes中间件会拦截请求先判断上下文中的令牌类型是否为TokenTypePersonalAccessToken若是则调用scopeFetcher.FetchTokenScopes(ctx, token)获取作用域列表并把结果写入请求上下文ghcontext.WithTokenScopes供后续工具过滤使用。FetchTokenScopes的核心实现pkg/scopes/fetcher.go#L65-L101如下向 GitHub API 根端点发送一次HTTP HEAD 请求只取响应头几乎不消耗带宽这正是“轻量”二字的来源携带Authorization: Bearer token从响应头的X-OAuth-Scopes中解析作用域列表逗号分隔ParseScopeHeader负责去空格拆分请求默认超时时间为 10 秒DefaultFetchTimeout并携带Accept: application/vnd.githubjson与X-GitHub-Api-Version: 2022-11-28头401 响应视为“无效或过期令牌”非 200 状态码直接返回错误。工具过滤发生在工具注册/列表阶段每个工具的ScopeAccess.Visible回调pkg/inventory/server_tool.go#L22-L47接收令牌的实际作用域返回false的工具即被隐藏。示例如果你的令牌只有repo和gist作用域那么依赖admin:org、project或notifications作用域的工具将不会出现在工具列表中。各类认证方式的作用域处理对比认证方式作用域处理策略Classic PATghp_服务启动时基于令牌作用域过滤工具缺少所需作用域的工具被隐藏OAuth仅远程服务器使用 OAuth scope challenge 机制工具全部可见调用缺少作用域的工具时提示用户按需授权Fine-grained PATgithub_pat_不过滤所有工具可见由 API 层强制执行权限GitHub Appghs_不过滤所有工具可见权限基于应用安装配置Server-to-server不过滤所有工具可见权限基于应用/令牌配置令牌类型判定逻辑位于 pkg/utils/token.go#L24-L30通过前缀识别ghp_classic PAT、github_pat_fine-grained PAT、gho_OAuth、ghu_GitHub App 用户令牌、ghs_GitHub App 安装令牌/server-to-server。注意2021 年之前签发的 40 位十六进制旧式令牌也会被识别为 classic PATpkg/utils/token.go#L39-L41。两种模式的取舍非常清晰OAuth 场景下作用域是动态可追加的按需授权即可而PAT 的作用域在创建令牌时就已固定无法在运行中追加因此服务选择“主动隐藏用不了的工具”。工具的两种作用域检查每个工具定义两个小型检查结构定义见 pkg/inventory/server_tool.go#L29-L47字段作用时机Visible可见性检查决定该工具对 classic PAT 是否可见工具列表构建时Challenge按调用检查返回 OAuth challenge 所需的精确作用域集合返回空则表示当前调用可以继续每次tools/call请求时关键在于Challenge回调接收本次调用的工具参数arguments map[string]any因此可以基于具体参数做精细化决策。仓库提供了几个典型实现pkg/github/tool_scopes.go仓库/组织双目标工具repositoryOrOrganizationScopeAccess根据参数动态判定——带repo参数时 challengerepo仅带owner且无repo时 challengeread:org如list_issue_fields、list_issue_types等见 pkg/github/issue_fields.go#L131文件写入常规文件写入只要求repo当调用涉及workflow 文件.github/workflows/下的文件时额外追加workflow作用域——因为 GitHub 对修改 Actions 工作流文件有独立的workflow权限要求这一行为由 pkg/github/public_repo_scopes_test.go#L88-L102 中的参数化测试逐一验证。此外DynamicChallengepkg/scopes/scopes.go#L157-L170要求声明“穷举的最大作用域上界”maxScopes中间件可据此在参数解码前快速短路若令牌已满足上界则跳过 challenge 求值见下文性能优化。OAuth Scope Challenges远程服务器的按需授权Remote Server当使用远程 MCP 服务器配合 OAuth 认证时服务采用截然不同的scope challenge策略不再预先隐藏工具而是全部工具可见在实际调用时按需请求额外作用域。完整流程对应 pkg/http/middleware/scope_challenge.go 的WithScopeChallenge中间件客户端尝试调用某个工具例如创建 issue中间件仅拦截tools/call请求_ping健康检查等端点直接放行并确认令牌类型为 OAuth 访问令牌TokenTypeOAuthAccessToken通过scopes.GetToolScopeAccess(toolName)查表拿到该工具的请求时策略pkg/scopes/map.go#L44-L47优先使用请求上下文中已有的作用域远程服务器可直接传入避免重复请求 GitHub API否则调用FetchTokenScopes拉取若令牌已满足该工具的最大作用域上界MaximumScopesSatisfiedpkg/scopes/map.go#L51-L53直接放行无需解码工具参数——这是针对“绝大多数调用本就授权充分”场景的热路径优化否则解码参数并执行该工具具体的Challenge回调得到本次调用缺失的精确作用域集合若集合非空构造WWW-Authenticate响应头并返回403WWW-Authenticate: Bearer errorinsufficient_scope, scope缺失作用域, resource_metadata资源元数据URL, error_descriptionAdditional scopes required: ...客户端收到 challenge 后提示用户授权该额外作用域授权完成后该操作继续执行并成功返回。这种模式显著改善 OAuth 用户的使用体验按需最小授权而不是启动时就一股脑请求全部作用域。该 challenge 策略表由工具清单Inventory构建pkg/scopes/map.go#L17-L41且只收录声明了Challenge回调的工具。查看自己令牌的作用域你可以直接用 curl 复现服务端的探测逻辑验证令牌当前携带了哪些作用域curl -sI -H Authorization: Bearer $GITHUB_PERSONAL_ACCESS_TOKEN \ https://api.github.com/user | grep -i x-oauth-scopes示例输出x-oauth-scopes: delete_repo, gist, read:org, repo注意HEAD 请求方式与仓库内Fetcher的实现一致pkg/scopes/fetcher.go#L77-L84你也可以把它当作排障时的对照命令。作用域层级Scope Hierarchy隐式包含关系某些作用域会隐式包含其他作用域服务在判定“令牌是否具备某作用域”时会递归走完整棵继承树实现见 pkg/scopes/scopes.go#L112-L122 与scopeImplies函数 pkg/scopes/scopes.go#L202-L215repo→ 包含public_repo、security_eventsadmin:org→ 包含write:org→ 包含read:orgproject→ 包含read:projectwrite:packages→ 包含read:packages源码中还有这一条文档未列user→ 包含read:user、user:email因此如果你的令牌有repo需要security_events的工具同样可用拥有admin:org时read:org级别的组织读取工具也全部可用。仓库中完整定义了服务可能用到的全部 OAuth 作用域常量NoScope、Repo、PublicRepo、DeleteRepo、ReadOrg、WriteOrg、AdminOrg、Gist、Notifications、ReadProject、Project、SecurityEvents、User、ReadUser、UserEmail、ReadPackages、WritePackages、Workflow、Codespace见 pkg/scopes/scopes.go#L12-L69并提供了DefaultOAuthScopes默认请求的低风险作用域集与SupportedOAuthScopes服务可能请求的全部作用域两个查询入口pkg/scopes/scopes.go#L92-L110。每个工具可能在 OAuth 场景下挑战的作用域均列在 README.md 的 Tools 一节中可用于查阅具体工具所需的精确作用域。公共仓库访问只读工具永远可见只依赖repo或public_repo作用域的只读工具始终可见即便令牌根本没有这些作用域——因为公共仓库的数据无需认证即可读取。典型例子get_file_contents任何时候都可用你可以读取任意公共仓库的文件但写操作如create_or_update_file在令牌缺少repo作用域时会被隐藏。实现上有两层保障PublicRead构造器pkg/scopes/scopes.go#L143-L147直接覆盖Visible为“恒可见”同时保留Challenge供 OAuth 按需授权公开仓库写工具的特殊策略publicRepositoryWriteScopeAccesspkg/github/tool_scopes.go#L8-L14可见性只看是否具备public_repo但 challenge 依旧要求repo——即“对公共仓库的写操作只需 public_repo 权限即可展示/执行”相关行为由 pkg/github/public_repo_scopes_test.go 参数化测试覆盖。重要提示GitHub API 不会在X-OAuth-Scopes响应头中返回public_repo——它是隐式的。服务通过“不过滤只读仓库工具”的方式处理这一特殊性。优雅降级作用域探测失败时的行为如果服务无法获取令牌作用域网络故障、API 限流等它不会拒绝服务而是记录一条警告并继续不启用过滤地运行WARN: failed to fetch token scopes, continuing without scope filtering对应实现位于 pkg/http/middleware/pat_scope.go#L36-L41FetchTokenScopes返回错误时仅logger.Warn后直接放行请求。这条设计保证了即使作用域检测失效服务器依然可用所有工具可见把故障影响降到最低。Classic 与 Fine-grained PAT 的区别Classic PATghp_前缀基于 OAuth 作用域模型会在X-OAuth-Scopes头中返回作用域作用域过滤对其完整生效。Fine-grained PATgithub_pat_前缀采用基于“仓库访问范围 具体权限项”的另一种权限模型不返回X-OAuth-Scopes头因此作用域过滤被跳过所有工具可见。但 GitHub API 仍会在 API 层强制权限——你调用无权限的工具时依然会得到报错。从源码看WithPATScopes中间件明确只对TokenTypePersonalAccessToken执行探测pkg/http/middleware/pat_scope.go#L28其他令牌类型一律跳过Fetcher对缺失头的情况返回空切片pkg/scopes/fetcher.go#L106-L120同样不触发过滤。GitHub App 与 Server-to-Server 令牌GitHub App 安装令牌ghs_前缀及其他 server-to-server 令牌的权限模型基于应用的安装权限而非 OAuth 作用域。它们同样不返回X-OAuth-Scopes头因此作用域过滤被跳过权限由 GitHub API 依据应用配置强制执行。故障排查问题原因解决办法缺少预期中的工具令牌缺少所需作用域在 GitHub 设置页面编辑 PAT 的作用域令牌受限却看到全部工具作用域探测失败检查日志中关于 scope 获取的警告信息出现 “Insufficient permissions” 错误工具可见但作用域不足在作用域过滤正常时本不应发生请作为 bug 上报小贴士你可以随时在 GitHub 的令牌设置页面调整已有 classic PAT 的作用域。修改作用域后重启 MCP Server才能让新作用域生效作用域在启动阶段完成探测。相关文档服务器配置指南涵盖启动参数、环境变量与认证方式配置远程服务器部署OAuth 与 scope challenge 场景的部署说明OAuth 登录远程服务器的 OAuth 授权流程README.md完整的工具列表及其对应作用域【免费下载链接】github-mcp-serverGitHubs official MCP Server项目地址: https://gitcode.com/GitHub_Trending/gi/github-mcp-server创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 GitHub MCP Server 作用域过滤（Scope Filtering）原理与实战指南：PAT、OAuth 与工具可见性控制
GitHub MCP Server 作用域过滤Scope Filtering原理与实战指南PAT、OAuth 与工具可见性控制【免费下载链接】github-mcp-serverGitHubs official MCP Server项目地址: https://gitcode.com/GitHub_Trending/gi/github-mcp-serverGitHub 官方 MCP Servergithub-mcp-server提供了一套基于认证令牌 OAuth 作用域的自动化工具过滤机制当你使用 classic PAT 启动服务时服务器会主动探测令牌携带的作用域并隐藏那些当前令牌无权调用的工具从而减少工具列表噪音、提前规避“权限不足”类错误。本文以 docs/scope-filtering.md 为主体结合仓库源码pkg/scopes、pkg/http/middleware、pkg/inventory 等逐层拆解其工作原理、配置方法、scope 层级推导规则、OAuth 场景挑战机制与常见故障排查帮助你在本地与远程部署中精确控制 MCP 工具面。概述什么是 PAT 作用域过滤GitHub MCP Server 会根据你提供的classic Personal Access TokenPAT以ghp_开头的传统令牌的 OAuth 作用域自动过滤可供使用的 MCP 工具。这样做的目的有两个减少噪音只展示当前令牌真正有权调用的工具避免工具列表中出现大量注定失败的选项预防错误提前隐藏需要不可用作用域的工具从源头避免“调用时报 403/Insufficient permissions”的尴尬。该功能有明确的前提边界仅适用于 classic PAT。Fine-grained PAT、GitHub App 安装令牌ghs_开头以及 server-to-server 令牌不支持作用域探测服务会展示全部工具。工作原理一次轻量 HEAD 请求探测令牌作用域从 pkg/scopes/fetcher.go 的实现可以看到完整链路当服务以 classic PAT 启动后pkg/http/middleware/pat_scope.go 中的WithPATScopes中间件会拦截请求先判断上下文中的令牌类型是否为TokenTypePersonalAccessToken若是则调用scopeFetcher.FetchTokenScopes(ctx, token)获取作用域列表并把结果写入请求上下文ghcontext.WithTokenScopes供后续工具过滤使用。FetchTokenScopes的核心实现pkg/scopes/fetcher.go#L65-L101如下向 GitHub API 根端点发送一次HTTP HEAD 请求只取响应头几乎不消耗带宽这正是“轻量”二字的来源携带Authorization: Bearer token从响应头的X-OAuth-Scopes中解析作用域列表逗号分隔ParseScopeHeader负责去空格拆分请求默认超时时间为 10 秒DefaultFetchTimeout并携带Accept: application/vnd.githubjson与X-GitHub-Api-Version: 2022-11-28头401 响应视为“无效或过期令牌”非 200 状态码直接返回错误。工具过滤发生在工具注册/列表阶段每个工具的ScopeAccess.Visible回调pkg/inventory/server_tool.go#L22-L47接收令牌的实际作用域返回false的工具即被隐藏。示例如果你的令牌只有repo和gist作用域那么依赖admin:org、project或notifications作用域的工具将不会出现在工具列表中。各类认证方式的作用域处理对比认证方式作用域处理策略Classic PATghp_服务启动时基于令牌作用域过滤工具缺少所需作用域的工具被隐藏OAuth仅远程服务器使用 OAuth scope challenge 机制工具全部可见调用缺少作用域的工具时提示用户按需授权Fine-grained PATgithub_pat_不过滤所有工具可见由 API 层强制执行权限GitHub Appghs_不过滤所有工具可见权限基于应用安装配置Server-to-server不过滤所有工具可见权限基于应用/令牌配置令牌类型判定逻辑位于 pkg/utils/token.go#L24-L30通过前缀识别ghp_classic PAT、github_pat_fine-grained PAT、gho_OAuth、ghu_GitHub App 用户令牌、ghs_GitHub App 安装令牌/server-to-server。注意2021 年之前签发的 40 位十六进制旧式令牌也会被识别为 classic PATpkg/utils/token.go#L39-L41。两种模式的取舍非常清晰OAuth 场景下作用域是动态可追加的按需授权即可而PAT 的作用域在创建令牌时就已固定无法在运行中追加因此服务选择“主动隐藏用不了的工具”。工具的两种作用域检查每个工具定义两个小型检查结构定义见 pkg/inventory/server_tool.go#L29-L47字段作用时机Visible可见性检查决定该工具对 classic PAT 是否可见工具列表构建时Challenge按调用检查返回 OAuth challenge 所需的精确作用域集合返回空则表示当前调用可以继续每次tools/call请求时关键在于Challenge回调接收本次调用的工具参数arguments map[string]any因此可以基于具体参数做精细化决策。仓库提供了几个典型实现pkg/github/tool_scopes.go仓库/组织双目标工具repositoryOrOrganizationScopeAccess根据参数动态判定——带repo参数时 challengerepo仅带owner且无repo时 challengeread:org如list_issue_fields、list_issue_types等见 pkg/github/issue_fields.go#L131文件写入常规文件写入只要求repo当调用涉及workflow 文件.github/workflows/下的文件时额外追加workflow作用域——因为 GitHub 对修改 Actions 工作流文件有独立的workflow权限要求这一行为由 pkg/github/public_repo_scopes_test.go#L88-L102 中的参数化测试逐一验证。此外DynamicChallengepkg/scopes/scopes.go#L157-L170要求声明“穷举的最大作用域上界”maxScopes中间件可据此在参数解码前快速短路若令牌已满足上界则跳过 challenge 求值见下文性能优化。OAuth Scope Challenges远程服务器的按需授权Remote Server当使用远程 MCP 服务器配合 OAuth 认证时服务采用截然不同的scope challenge策略不再预先隐藏工具而是全部工具可见在实际调用时按需请求额外作用域。完整流程对应 pkg/http/middleware/scope_challenge.go 的WithScopeChallenge中间件客户端尝试调用某个工具例如创建 issue中间件仅拦截tools/call请求_ping健康检查等端点直接放行并确认令牌类型为 OAuth 访问令牌TokenTypeOAuthAccessToken通过scopes.GetToolScopeAccess(toolName)查表拿到该工具的请求时策略pkg/scopes/map.go#L44-L47优先使用请求上下文中已有的作用域远程服务器可直接传入避免重复请求 GitHub API否则调用FetchTokenScopes拉取若令牌已满足该工具的最大作用域上界MaximumScopesSatisfiedpkg/scopes/map.go#L51-L53直接放行无需解码工具参数——这是针对“绝大多数调用本就授权充分”场景的热路径优化否则解码参数并执行该工具具体的Challenge回调得到本次调用缺失的精确作用域集合若集合非空构造WWW-Authenticate响应头并返回403WWW-Authenticate: Bearer errorinsufficient_scope, scope缺失作用域, resource_metadata资源元数据URL, error_descriptionAdditional scopes required: ...客户端收到 challenge 后提示用户授权该额外作用域授权完成后该操作继续执行并成功返回。这种模式显著改善 OAuth 用户的使用体验按需最小授权而不是启动时就一股脑请求全部作用域。该 challenge 策略表由工具清单Inventory构建pkg/scopes/map.go#L17-L41且只收录声明了Challenge回调的工具。查看自己令牌的作用域你可以直接用 curl 复现服务端的探测逻辑验证令牌当前携带了哪些作用域curl -sI -H Authorization: Bearer $GITHUB_PERSONAL_ACCESS_TOKEN \ https://api.github.com/user | grep -i x-oauth-scopes示例输出x-oauth-scopes: delete_repo, gist, read:org, repo注意HEAD 请求方式与仓库内Fetcher的实现一致pkg/scopes/fetcher.go#L77-L84你也可以把它当作排障时的对照命令。作用域层级Scope Hierarchy隐式包含关系某些作用域会隐式包含其他作用域服务在判定“令牌是否具备某作用域”时会递归走完整棵继承树实现见 pkg/scopes/scopes.go#L112-L122 与scopeImplies函数 pkg/scopes/scopes.go#L202-L215repo→ 包含public_repo、security_eventsadmin:org→ 包含write:org→ 包含read:orgproject→ 包含read:projectwrite:packages→ 包含read:packages源码中还有这一条文档未列user→ 包含read:user、user:email因此如果你的令牌有repo需要security_events的工具同样可用拥有admin:org时read:org级别的组织读取工具也全部可用。仓库中完整定义了服务可能用到的全部 OAuth 作用域常量NoScope、Repo、PublicRepo、DeleteRepo、ReadOrg、WriteOrg、AdminOrg、Gist、Notifications、ReadProject、Project、SecurityEvents、User、ReadUser、UserEmail、ReadPackages、WritePackages、Workflow、Codespace见 pkg/scopes/scopes.go#L12-L69并提供了DefaultOAuthScopes默认请求的低风险作用域集与SupportedOAuthScopes服务可能请求的全部作用域两个查询入口pkg/scopes/scopes.go#L92-L110。每个工具可能在 OAuth 场景下挑战的作用域均列在 README.md 的 Tools 一节中可用于查阅具体工具所需的精确作用域。公共仓库访问只读工具永远可见只依赖repo或public_repo作用域的只读工具始终可见即便令牌根本没有这些作用域——因为公共仓库的数据无需认证即可读取。典型例子get_file_contents任何时候都可用你可以读取任意公共仓库的文件但写操作如create_or_update_file在令牌缺少repo作用域时会被隐藏。实现上有两层保障PublicRead构造器pkg/scopes/scopes.go#L143-L147直接覆盖Visible为“恒可见”同时保留Challenge供 OAuth 按需授权公开仓库写工具的特殊策略publicRepositoryWriteScopeAccesspkg/github/tool_scopes.go#L8-L14可见性只看是否具备public_repo但 challenge 依旧要求repo——即“对公共仓库的写操作只需 public_repo 权限即可展示/执行”相关行为由 pkg/github/public_repo_scopes_test.go 参数化测试覆盖。重要提示GitHub API 不会在X-OAuth-Scopes响应头中返回public_repo——它是隐式的。服务通过“不过滤只读仓库工具”的方式处理这一特殊性。优雅降级作用域探测失败时的行为如果服务无法获取令牌作用域网络故障、API 限流等它不会拒绝服务而是记录一条警告并继续不启用过滤地运行WARN: failed to fetch token scopes, continuing without scope filtering对应实现位于 pkg/http/middleware/pat_scope.go#L36-L41FetchTokenScopes返回错误时仅logger.Warn后直接放行请求。这条设计保证了即使作用域检测失效服务器依然可用所有工具可见把故障影响降到最低。Classic 与 Fine-grained PAT 的区别Classic PATghp_前缀基于 OAuth 作用域模型会在X-OAuth-Scopes头中返回作用域作用域过滤对其完整生效。Fine-grained PATgithub_pat_前缀采用基于“仓库访问范围 具体权限项”的另一种权限模型不返回X-OAuth-Scopes头因此作用域过滤被跳过所有工具可见。但 GitHub API 仍会在 API 层强制权限——你调用无权限的工具时依然会得到报错。从源码看WithPATScopes中间件明确只对TokenTypePersonalAccessToken执行探测pkg/http/middleware/pat_scope.go#L28其他令牌类型一律跳过Fetcher对缺失头的情况返回空切片pkg/scopes/fetcher.go#L106-L120同样不触发过滤。GitHub App 与 Server-to-Server 令牌GitHub App 安装令牌ghs_前缀及其他 server-to-server 令牌的权限模型基于应用的安装权限而非 OAuth 作用域。它们同样不返回X-OAuth-Scopes头因此作用域过滤被跳过权限由 GitHub API 依据应用配置强制执行。故障排查问题原因解决办法缺少预期中的工具令牌缺少所需作用域在 GitHub 设置页面编辑 PAT 的作用域令牌受限却看到全部工具作用域探测失败检查日志中关于 scope 获取的警告信息出现 “Insufficient permissions” 错误工具可见但作用域不足在作用域过滤正常时本不应发生请作为 bug 上报小贴士你可以随时在 GitHub 的令牌设置页面调整已有 classic PAT 的作用域。修改作用域后重启 MCP Server才能让新作用域生效作用域在启动阶段完成探测。相关文档服务器配置指南涵盖启动参数、环境变量与认证方式配置远程服务器部署OAuth 与 scope challenge 场景的部署说明OAuth 登录远程服务器的 OAuth 授权流程README.md完整的工具列表及其对应作用域【免费下载链接】github-mcp-serverGitHubs official MCP Server项目地址: https://gitcode.com/GitHub_Trending/gi/github-mcp-server创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考