koishi-plugin-kkk 3.3.0-beta.2 → 3.3.0-beta.3

package/CHANGELOG.md

@@ -1,5 +1,11 @@
 # 更新日志
 
+## 3.3.0-beta.3
+
+### 修了两个「设置根本没生效」的问题
+
+- **「强制在线播放的适配器」这类设置以前是静默失效的**：运行时配置是一份**手写白名单**，新加的开关（强制在线播放的适配器、面板「在线看」列、按需切片、解析去重…）忘了往里补一行，运行时读到的就是 undefined —— 表现就是 B站私聊明明配了强制在线播放，**还是去下载并发视频文件**。现在改成「字段表里的默认值打底 + 归一化覆盖」，以后再加开关不会漏。
+- **不支持的适配器不再尝试合并转发**：判断「这个适配器支不支持聊天记录」用的是**黑名单**（只排除 QQ 官方），于是任何自定义适配器都被当成支持 —— B站私聊适配器（platform 就是 bilibili）也被算进去了，整条转发发出去「没有拿到消息 ID」，连退回来的逐条发送也失败，用户什么都没收到。现在改成**白名单**（OneBot 系平台名，或适配器自带 sendGroupForwardMsg/sendPrivateForwardMsg），并会在日志里写明「适配器 xxx 不支持合并转发，本次逐条发送」。
 ## 3.3.0-beta.2
 
 > **预览版**：给愿意先试的人用。npm 上默认安装的（latest）还是 3.2.2，想装这个用 npm i koishi-plugin-kkk@beta（或者面板里的「检查更新」换成 beta 通道）。

package/lib/index.js

@@ -892,7 +892,16 @@ async function apply(ctx, rawConfig) {
         if (raw[key] !== undefined)
             legacy[key] = raw[key];
     }
-    const groupQq = { ...(qq ?? {}) };
+    /**
+     * **每个 qq 字段都要有值**：不能指望 Koishi 的 schema 默认值一定被填上 ——
+     * 线上实测踩过（用户报「B站私聊还是发视频、没给在线播放链接」）：
+     * 配置里没写过的字段，运行时读到的是 `undefined`，
+     * 于是「强制在线播放的适配器」（默认 bilibili）整个失效、面板列按钮的开关也失效。
+     *
+     * 所以这里用 `readQqOptions` 先铺一层**字段表里的默认值**（qqFields.json 是唯一出处），
+     * 再用用户显式配的值覆盖 —— 显式配置永远优先，缺的字段一律有默认。
+     */
+    const groupQq = { ...(0, qqOptions_1.readQqOptions)(raw), ...(qq ?? {}) };
     const groupNative = { ...(advanced ?? {}) };
     for (const key of qqOptions_1.QQ_KEYS)
         if (legacy[key] !== undefined)
@@ -952,7 +961,18 @@ async function apply(ctx, rawConfig) {
     const dataRoot = node_path_1.default.isAbsolute(config.dataPath) ? config.dataPath : node_path_1.default.resolve(ctx.baseDir ?? process.cwd(), config.dataPath);
     (0, runtime_1.bindRuntime)({
         ctx,
+        /**
+         * ⚠️ 这份 config **不是**原封不动转发，而是运行时真正读的那一份（`tryGetRuntime().config`）。
+         *
+         * 以前它是一个**手写白名单** —— 于是每加一个新开关（例如「强制在线播放的适配器」
+         * `forceOnlinePlayer`），忘了往这里补一行，运行时就读到 undefined，功能整个静默失效：
+         * 线上真实故障就是「B站私聊该给在线播放链接，结果还是去发视频文件」。
+         *
+         * 现在改成 `...readQqOptions(config)` 打底（qqFields.json 里的字段一个不落，缺的用默认值），
+         * 下面那些需要**归一化**的字段（端口取整数、分钟数夹范围、布尔用 !== false 这种）再覆盖上去。
+         */
         config: {
+            ...(0, qqOptions_1.readQqOptions)(config),
             masters: config.masters ?? [],
             debug: config.debug,
             dataPath: config.dataPath,

package/lib/karin/module/utils/ParseForward.js

@@ -41,9 +41,31 @@ function parseForwardPeer(e) {
 function platformOf(e) {
     return String(e?.bot?.bot?.platform ?? e?.bot?.platform ?? '');
 }
-/** 这台部署的适配器支不支持合并转发 */
+/**
+ * OneBot 系适配器（NapCat / Lagrange / go-cqhttp / Chronocat…）：它们真的有「聊天记录」这个概念。
+ *
+ * 注意这份名单是**白名单**：compat 那边的 isForwardSupported 是黑名单（只排除 QQ 官方），
+ * 于是**任何自定义适配器都会被当成支持** —— 线上真实故障就是这样：
+ * B站私聊适配器（koishi-plugin-adapter-bilibili-dm，platform 就是 bilibili）被认成支持合并转发，
+ * 结果整条转发发出去「没有拿到消息 ID」（适配器根本没有聊天记录这种东西），
+ * 连退回来的逐条发送也失败了 —— 用户什么都没收到。
+ */
+const ONEBOT_LIKE = /onebot|napcat|lagrange|go-?cqhttp|chronocat|mirai/i;
+/** 这台部署的适配器支不支持合并转发（**只有明确支持才算支持**） */
 function canForwardParseResult(e) {
-    return (0, node_karin_1.isForwardSupported)({ platform: platformOf(e) });
+    const raw = e?.bot?.bot ?? e?.bot;
+    /**
+     * ① 适配器自己带合并转发 API（OneBot 系的 sendGroupForwardMsg / sendPrivateForwardMsg）
+     *    —— 这条最可靠，不依赖平台名怎么写。
+     */
+    const internal = raw?.internal ?? e?.bot?.internal;
+    if (internal && (typeof internal.sendGroupForwardMsg === 'function' || typeof internal.sendPrivateForwardMsg === 'function'))
+        return true;
+    /** ② 其余只认 OneBot 系的平台名 */
+    const platform = platformOf(e);
+    if (!platform)
+        return false;
+    return ONEBOT_LIKE.test(platform);
 }
 /** 平台名 → 配置段名（合并转发的平台开关就写在各自的平台段里） */
 const PLATFORM_SECTIONS = {
@@ -311,8 +333,13 @@ function withParseForward(handler, platform) {
                 + '.forward 都没打开），按逐条发送处理');
             return await handler(e, next);
         }
-        if (!parseForwardPeer(e) || !canForwardParseResult(e))
+        if (!parseForwardPeer(e))
             return await handler(e, next);
+        if (!canForwardParseResult(e)) {
+            // 说明白为什么没合并：以前这里静默退化，用户只看到「转发了但没收到」
+            node_karin_1.logger.mark('[合并转发] 适配器 ' + (platformOf(e) || '未知') + ' 不支持合并转发（不是 OneBot 系、也没有 forward API），本次逐条发送');
+            return await handler(e, next);
+        }
         return await (0, node_karin_1.runWithForwardBag)(parseForwardPeer(e), async () => {
             try {
                 return await handler(e, next);

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "koishi-plugin-kkk",
-  "version": "3.3.0-beta.2",
+  "version": "3.3.0-beta.3",
   "description": "抖音 / B站 / 快手 / 小红书 视频解析与动态推送，带 QQ 交互面板与弹幕烧录（karin-plugin-kkk 的 Koishi 移植版）",
   "main": "lib/index.js",
   "typings": "lib/index.d.ts",

package/src/index.ts

@@ -885,7 +885,16 @@ export async function apply (ctx: Context, rawConfig: Config) {
   for (const key of [...NATIVE_KEYS, ...QQ_KEYS]) {
     if (raw[key] !== undefined) legacy[key] = raw[key]
   }
-  const groupQq: any = { ...(qq ?? {}) }
+  /**
+   * **每个 qq 字段都要有值**：不能指望 Koishi 的 schema 默认值一定被填上 ——
+   * 线上实测踩过（用户报「B站私聊还是发视频、没给在线播放链接」）：
+   * 配置里没写过的字段，运行时读到的是 `undefined`，
+   * 于是「强制在线播放的适配器」（默认 bilibili）整个失效、面板列按钮的开关也失效。
+   *
+   * 所以这里用 `readQqOptions` 先铺一层**字段表里的默认值**（qqFields.json 是唯一出处），
+   * 再用用户显式配的值覆盖 —— 显式配置永远优先，缺的字段一律有默认。
+   */
+  const groupQq: any = { ...readQqOptions(raw as any), ...(qq ?? {}) }
   const groupNative: any = { ...(advanced ?? {}) }
   for (const key of QQ_KEYS) if (legacy[key] !== undefined) groupQq[key] = legacy[key]
   for (const key of NATIVE_KEYS) if (legacy[key] !== undefined) groupNative[key] = legacy[key]
@@ -940,7 +949,18 @@ export async function apply (ctx: Context, rawConfig: Config) {
 
   bindRuntime({
     ctx,
+    /**
+     * ⚠️ 这份 config **不是**原封不动转发，而是运行时真正读的那一份（`tryGetRuntime().config`）。
+     *
+     * 以前它是一个**手写白名单** —— 于是每加一个新开关（例如「强制在线播放的适配器」
+     * `forceOnlinePlayer`），忘了往这里补一行，运行时就读到 undefined，功能整个静默失效：
+     * 线上真实故障就是「B站私聊该给在线播放链接，结果还是去发视频文件」。
+     *
+     * 现在改成 `...readQqOptions(config)` 打底（qqFields.json 里的字段一个不落，缺的用默认值），
+     * 下面那些需要**归一化**的字段（端口取整数、分钟数夹范围、布尔用 !== false 这种）再覆盖上去。
+     */
     config: {
+      ...readQqOptions(config),
       masters: config.masters ?? [],
       debug: config.debug,
       dataPath: config.dataPath,

package/src/karin/module/utils/ParseForward.ts

@@ -35,9 +35,30 @@ function platformOf (e: any): string {
   return String(e?.bot?.bot?.platform ?? e?.bot?.platform ?? '')
 }
 
-/** 这台部署的适配器支不支持合并转发 */
+/**
+ * OneBot 系适配器（NapCat / Lagrange / go-cqhttp / Chronocat…）：它们真的有「聊天记录」这个概念。
+ *
+ * 注意这份名单是**白名单**：compat 那边的 isForwardSupported 是黑名单（只排除 QQ 官方），
+ * 于是**任何自定义适配器都会被当成支持** —— 线上真实故障就是这样：
+ * B站私聊适配器（koishi-plugin-adapter-bilibili-dm，platform 就是 bilibili）被认成支持合并转发，
+ * 结果整条转发发出去「没有拿到消息 ID」（适配器根本没有聊天记录这种东西），
+ * 连退回来的逐条发送也失败了 —— 用户什么都没收到。
+ */
+const ONEBOT_LIKE = /onebot|napcat|lagrange|go-?cqhttp|chronocat|mirai/i
+
+/** 这台部署的适配器支不支持合并转发（**只有明确支持才算支持**） */
 export function canForwardParseResult (e: any): boolean {
-  return isForwardSupported({ platform: platformOf(e) })
+  const raw: any = e?.bot?.bot ?? e?.bot
+  /**
+   * ① 适配器自己带合并转发 API（OneBot 系的 sendGroupForwardMsg / sendPrivateForwardMsg）
+   *    —— 这条最可靠，不依赖平台名怎么写。
+   */
+  const internal: any = raw?.internal ?? e?.bot?.internal
+  if (internal && (typeof internal.sendGroupForwardMsg === 'function' || typeof internal.sendPrivateForwardMsg === 'function')) return true
+  /** ② 其余只认 OneBot 系的平台名 */
+  const platform = platformOf(e)
+  if (!platform) return false
+  return ONEBOT_LIKE.test(platform)
 }
 
 /** 平台名 → 配置段名（合并转发的平台开关就写在各自的平台段里） */
@@ -302,7 +323,12 @@ export function withParseForward<F extends (e: any, next?: any) => any> (handler
         + '.forward 都没打开），按逐条发送处理')
       return await handler(e, next)
     }
-    if (!parseForwardPeer(e) || !canForwardParseResult(e)) return await handler(e, next)
+    if (!parseForwardPeer(e)) return await handler(e, next)
+    if (!canForwardParseResult(e)) {
+      // 说明白为什么没合并：以前这里静默退化，用户只看到「转发了但没收到」
+      logger.mark('[合并转发] 适配器 ' + (platformOf(e) || '未知') + ' 不支持合并转发（不是 OneBot 系、也没有 forward API），本次逐条发送')
+      return await handler(e, next)
+    }
     return await runWithForwardBag(parseForwardPeer(e), async () => {
       try {
         return await handler(e, next)