是使用模板项目启动的，使用 ctx.http 时改过全局代理，使用全局代理时无法打开插件市场，然后就把全局代理配置项清空了，再之后插件市场就出现了这个问题 ，但是可以正常加载使用 。
今天早上又出现了新的问题
所有依赖无法获取版本，日志中也有好几屏（几十条 “[W] market connect ECONNREFUSED 127.0.0.1:80” 报错）
插件市场可以搜索到插件但是无法修改和添加
也许可以在 auth 插件中增加一个配置项, 不论原有插件是否开放, 均对外部用户不可见, 这个选项可以覆盖所有插件的可见性设置
我也不清楚这是怎么出现的了，到处折腾一下，有时手动增加了一些插件或者修改配置网页就会自动刷新。我现在重启浏览器之后再尝试登出登录，那个只有一个叉叉的提示神奇地消失了。
这样操作并移除 SUPERUSER 权限之后确实可以正常使用了，感谢。（但没有测试过从零开始是否有效）
建议在 database-postgres 插件的 usage 描述中增加对权限要求的描述, 并提醒用户不要直接使用数据库的 SUPERUSER 用户以增加数据库安全性。
确保积极响应 《Koishi 实例安全性公告 》文件的相关政策。
当时我在开发插件，已经 extend 了一个数据表，但是某个字段设计有问题想更改，直接更改字段名之后发现原有字段还残留在数据表中，我想着还没有数据就直接把整个表删除重新创建，然后就使用了这个 drop 方法。
当时的上下文是
export function apply(ctx: Context) {
ctx.database.drop(‘一个不存在的表’);
ctx.model.extend("...", { ... });
}
ctx.database.drop 实际上是一个异步方法，但我当时没有注意到这一点，忘了加 await 关键字，不清楚这个问题是否和异步操作有关。
为什么会 drop 到一个不存在的表？因为有 hmr，我的字没打完就自动重载触发了这个语句。
然后就是不知怎么回事重启 koishi 之后 “koishi” 数据库就被重置了，对于开发者来说这是毁灭性的影响。如果使用了其他插件并存储了一些数据，那么这些数据都会消失。
首先建议 koishi 提高数据库插件自身的 Robustness 和安全性，不管插件开发者怎么折腾都不会把整个数据库重置；插件也许可以做更精细的权限控制，比如默认没有删除表的权限、只能删除由该插件声明的表等等。
其次是完善文档，如果 任何时候都不推荐 插件 使用数据库的 drop 功能，那么应该在 数据库操作 (Database) | Koishi 这个 api 旁边注明他的危险性以及可能的严重后果，增加一个类似插件市场中不安全插件的图标标识。
然后如果可能的话，再出一个数据库备份插件，因为数据无价。