发布与审核标准

发布流程

① 创建应用：在「我的应用 → 创建应用」定下应用标识（英文名，如 mt-shop）与类型（插件 / 主题），提交后立刻得到应用 ID 与密钥。标识与类型创建后不可更改 —— 标识同时是安装目录名、仓库路径段与授权记录的键，改掉就等于把存量授权指向一个不存在的目录。

② 上传版本：进入该应用上传 zip。包内 manifest.json 的 name 必须等于应用标识，不一致会被当场拒绝。这道闸拦的是「产物落到 A 应用的目录、版本记录却挂在 B 应用上」——一旦错位，下载地址与授权对象就对不上了。

③ 机械校验与扫描：manifest 完整性 → 包名规则 → 归属检查（标识是否已被官方或其他开发者占用）→ 静态风险扫描 → 待审入库。任何一步不通过都当场拒绝，不会进入审核队列。

④ 人工审核：审核通过后版本才生效；首个版本过审同时让应用上架（在此之前应用不出现在商店里），后续版本过审只更新线上版本。

⑤ 应用资料（名称、简介、分类、图标、主页）在门户里维护，上传新版本不会被包内 manifest 的文案覆盖，可以放心迭代。

静态风险扫描（命中即拒）

eval()、create_function()、assert() 等动态执行函数。

exec()、system()、shell_exec()、passthru()、proc_open()、popen() 等命令执行函数。

base64_decode(gzinflate(...)) 这类常见的混淆后门写法。

向 app/、config/、route/、public/ 等核心目录直接写文件的行为。

扫描报告会留存并展示给审核员，请勿尝试绕过；绕过行为会被视为恶意提交并禁用账号。

常见驳回原因

功能与描述不符，或说明文档缺失关键信息（安装方式、依赖项、授权范围）。

包内包含未声明的外部请求、埋点回传或付费墙后门。

覆盖核心文件而非使用插件机制，导致核心升级即冲突。

定价与实际功能不匹配，或把免费功能放进付费增值项里人为设限。