fix(drivers/189pc,drivers/189tv): fix extra requests when viewing files

[wzdc]

Summary / 摘要

原有代码中，翻页的终止条件只判断了 Count == 0（总数为0），但并未判断当前返回的文件数量是否未达到数量，导致额外请求获取下一页的文件。这里添加了判断返回的文件数量是否达到所设置的pageSize才触发请求下一页。

fileListAO.count获取的是当前文件夹下总共的文件数量而不是当前返回的文件数量，但实际测试发现：当你请求的页码超出实际范围时（比如总共只有 3 页，你却请求第 4 页），接口返回的 Count 变成了 0。

• This PR has breaking changes.
  / 此 PR 包含破坏性变更。
• This PR changes public API, config, storage format, or migration behavior.
  / 此 PR 修改了公开 API、配置、存储格式或迁移行为。
• This PR requires corresponding changes in related repositories.
  / 此 PR 需要关联仓库同步修改。

Related repository PRs / 关联仓库 PR:

• OpenList-Frontend:
• OpenList-Docs:

Related Issues / 关联 Issue

Testing / 测试

• go test ./...
• Manual test / 手动测试: 编译运行后使用网络调试工具检查网络请求行为

Checklist / 检查清单

• I have read CONTRIBUTING.
  / 我已阅读 CONTRIBUTING。
• I confirm this contribution follows the repository license, contribution policy, and code of conduct.
  / 我确认此贡献符合仓库许可证、贡献规范和行为准则。
• I have formatted the changed code with gofmt, go fmt, or prettier where applicable.
  / 我已按适用情况使用 gofmt、go fmt 或 prettier 格式化变更代码。
• I have requested review from relevant maintainers or code owners where applicable.
  / 我已在适用情况下请求相关维护者或代码所有者审查。

AI Disclosure / AI 使用声明

• This PR includes AI-assisted content.
  / 此 PR 包含 AI 辅助内容。

Tools used / 使用工具:

• ChatGPT
• Codex
• GitHub Copilot
• Claude
• Gemini
• Other (please specify) / 其他（请注明）:

Usage scope / 使用范围:

• Code generation / 代码生成

• Refactoring / 重构

• Documentation / 文档

• Tests / 测试

• Translation / 翻译

• Review assistance / 审查辅助

• I have reviewed and validated all AI-assisted content included in this PR.
  / 我已审核并验证此 PR 中的所有 AI 辅助内容。

• I have ensured that all AI-assisted commits include Co-Authored-By attribution.
  / 我已确保所有 AI 辅助提交都包含 Co-Authored-By 归属信息。

• I can reproduce all AI-assisted content included in this PR without any AI tools.
  / 我可以在没有任何 AI 工具的情况下重现此 PR 中包含的所有 AI 辅助内容。

[jyxjjj]

建议复用请求时使用的 pageSize，避免再次硬编码 130 和 1000，否则以后修改分页大小时容易遗漏这里。

[pikachuren]

🙏 感谢贡献

感谢 @wzdc 提交此PR！我已完成代码评审，以下是评审结果。

---

🤖 AI 自动审核声明

本评审报告由 AI 自动生成，当前使用 Claude Opus 5 模型进行分析，部分复杂场景可能辅助使用 ChatGPT、DeepSeek 等模型进行交叉验证。

⚠️ AI 分析结果仅供参考，可能存在误判或遗漏。如您发现任何问题或有不同意见，欢迎随时提出讨论和纠正。

⚠️ 重要提醒：即使 AI 评审认为代码质量良好且建议合并，最终是否合并仍需由项目维护者进行人工判定。项目维护者会综合考虑代码质量、项目规划、技术方向、团队资源等多方面因素做出决策。

---

📖 PR背景与需求

PR标题：fix(drivers/189pc,drivers/189tv): fix extra requests when viewing files

关联Issue：无明确关联

需求说明：修复 189Cloud 驱动（189_tv 和 189pc）在文件列表翻页时的性能问题。当前实现在文件数量小于每页大小时仍会继续发送额外的分页请求，导致不必要的网络开销和性能损耗。

预期目标：

• 当返回的文件数量小于每页大小（pageSize）时，提前终止分页循环
• 减少不必要的 API 请求，提升文件浏览性能
• 保持与现有功能的兼容性

---

📋 问题摘要

• ✅ 功能性：修复了明确的性能问题，逻辑正确
• ✅ 代码质量：改动简洁明确，符合最小修改原则
• 💡 改进建议：无重大问题，但可以考虑边界情况和代码重复

---

📂 逐文件分析

drivers/189_tv/utils.go

改动意图：在 GetFiles 方法中修复翻页逻辑，避免在文件列表末尾发送额外请求

代码修改逻辑：

1. 保留原有的 pageNum 递增和分页请求逻辑
2. 核心修改：在每次分页请求后，新增文件数量判断逻辑

   FolderCount := len(resp.FileListAO.FolderList)
   FileCount := len(resp.FileListAO.FileList)
   PageCount := FolderCount + FileCount
   // 文件数量小于设定数量时跳出
   if PageCount < pageSize {
       break
   }

3. 当本次返回的文件+文件夹总数 < 130（pageSize）时，说明已经到了最后一页，提前终止循环

合理性评估：

• ✅ 优点：

  • 逻辑简洁明了，易于理解
  • 完全符合分页终止的常见模式（最后一页返回数量 < pageSize）
  • 改动最小化，只在必要位置插入判断逻辑
  • 无需修改接口或数据结构，向下兼容性良好

• ⚠️ 疑问：

  • pageSize 硬编码为 130，这个值是否与 API 请求参数中的 pageNum=130 保持一致？
  • 如果后续 API 调整每页大小，是否需要统一修改？

详细建议：

1. 代码规范：建议将 pageSize 提取为常量，避免魔法数字

   const pageSize = 130  // 189Cloud API 每页返回的文件数量

2. 边界情况：考虑 resp.FileListAO 为 nil 的情况（虽然当前代码在之前的判断中已有保护）
3. 性能优化：当前实现已经很优秀，无需进一步优化

---

drivers/189pc/utils.go

改动意图：与 189_tv 驱动保持一致，修复相同的翻页性能问题

代码修改逻辑：

• 完全相同的修改逻辑，在 GetFiles 方法中新增提前终止判断
• 代码结构和实现与 189_tv 一模一样

合理性评估：

• ✅ 优点：

  • 保持了两个驱动的代码一致性
  • 修复了相同的性能问题
  • 证明这是一个系统性问题，统一修复是正确的

• ⚠️ 疑问：

  • 189pc 和 189_tv 驱动的实现几乎完全相同，是否考虑过提取公共逻辑到 189_base 或者工具函数中？
  • 当前的代码重复可能导致未来维护成本增加（例如，如果需要调整分页逻辑，需要同时修改两处）

详细建议：

1. 长期优化（可选，不阻塞本次合并）：考虑将 189pc 和 189_tv 的通用分页逻辑提取到共享函数中

   // 在 drivers/189_common/utils.go 中
   func shouldStopPagination(folderCount, fileCount, pageSize int) bool {
       return (folderCount + fileCount) < pageSize
   }

2. 测试覆盖：虽然本次修改逻辑简单，但建议在实际 189Cloud 环境中测试以下场景：
   • 文件总数正好等于 130 的情况
   • 文件总数为 0 的空目录
   • 文件总数超过 1000 的大型目录（验证多次分页后正确终止）

---

🎯 总体评价

功能性：⭐⭐⭐⭐⭐ - 完美解决了明确的性能问题，逻辑正确且易于验证

安全性：⭐⭐⭐⭐⭐ - 无安全风险，纯粹的性能优化

代码质量：⭐⭐⭐⭐ - 代码清晰简洁，唯一的小瑕疵是两个驱动存在重复代码

实现方案：⭐⭐⭐⭐⭐ - 采用了分页终止的最佳实践，改动最小化

建议操作：

• ✅ Approve（建议合并）
• 🔄 Request Changes（需要修改）
• ❌ Close（建议关闭）

理由：
这是一个教科书级别的性能优化。修复明确、逻辑清晰、改动最小，完全符合"最小惊讶原则"。虽然存在一定的代码重复，但这不影响本次合并的价值。建议立即合并，代码重构可以作为后续独立的改进任务。

后续建议（不阻塞合并）：

1. 提取 pageSize 为常量
2. 考虑将 189pc 和 189_tv 的通用逻辑合并到共享模块
3. 在实际环境中测试边界情况（空目录、大型目录等）

非常优秀的性能优化！👍