太懂这种只能被动接收、没法要求发送方配合的憋屈了！靠一小时超时确实太粗犷，给你几个更靠谱的思路：

• 监控SFTP服务器的活跃连接
  你可以利用系统自带的网络工具直接跟踪连接状态，比如Linux下用ss -o state established '( dport = :sftp or sport = :sftp )'，或者netstat（部分系统仍可使用）。写个简单的脚本，定期检查有没有来自目标客户端IP的活跃SFTP连接：

  • 一旦检测到所有对应连接都断开了，再等个5-10分钟（留个缓冲时间，防止发送方最后收尾的小文件延迟），就触发批量处理。
  • 如果发送方可能分多次建立连接传同批次文件，那可以调整逻辑：记录连续无活跃连接的时长，达到设定值再启动处理。

• 解析SFTP服务器的会话日志
  绝大多数SFTP服务器（比如OpenSSH的sshd）都会在日志里记录会话的开启和关闭事件，比如在/var/log/auth.log（Debian/Ubuntu）或/var/log/secure（RHEL/CentOS）里，会有类似Accepted publickey for ...（会话开启）和session closed for user ...（会话关闭）的条目。
  你可以写个日志监控脚本（比如用tail -F实时跟踪），当捕捉到对应客户端用户/IP的会话关闭日志后，延迟几分钟就启动处理。这个方法最贴近真实的会话结束信号，比超时精准多了。
  注意要处理日志轮转的情况，避免漏读日志内容。

• 文件变化监控+连接状态双校验
  结合文件系统的事件监控工具（比如Linux的inotifywait、跨平台的fswatch）和连接状态检查：

  • 用工具监控接收目录的文件创建/修改事件，一旦有变化就重置计时器。
  • 同时定期检查有没有活跃的SFTP连接，如果没有连接，且计时器超过设定的短时长（比如5分钟），就触发批量处理。
    这种方式兼顾了“发送方可能在连接期间暂停传输”和“连接断开后无后续文件”的场景，比单纯的超时或单纯的连接监控更稳妥。

另外要提醒下：如果发送方可能用多个并发会话传文件，记得要统计来自同一客户端的所有活跃连接，必须全部断开后再触发处理，不然可能会漏掉后续传输的文件。

备注：内容来源于stack exchange，提问作者alsoeric