如何在Kotlin中优雅处理JRE的空迭代器接口

你说的这种JRE里的「空迭代器」接口我太熟了——就一个方法，返回null就表示没下一个元素了，用while(true)加Elvis break虽然能跑，但总觉得有点生硬，不够贴合Kotlin那种简洁优雅的风格对吧？我这儿有几个通用的方案，完全不用依赖特定类的额外方法（比如你说的不用ZipInputStream的available()），可以帮你把代码写得更“Kotlin味儿”：

1. 用序列（Sequence）封装，最通用的写法 #

Kotlin的Sequence天生适合这种懒加载的迭代场景，我们可以写个通用的扩展函数，把这个“取元素返回null结束”的方法直接转成Sequence，之后就能用Kotlin标准库的各种集合操作符了：

fun <T> (() -> T?).asSequence(): Sequence<T> = sequence {
    generateSequence { this@asSequence() }
        .takeWhile { it != null }
        .forEach { yield(it) }
}

// 实际用法示例
ZipInputStream(stream).use { zip ->
    zip::getNextEntry.asSequence()
        .filter { it.name.endsWith(".txt") }
        .forEach { println(it.name) }
}

这个扩展函数接受一个返回T?的函数（就是你的那个“取元素”方法），把它包装成Sequence。之后过滤、遍历这些操作都能直接用，完全摆脱while循环，代码逻辑也更聚焦于你真正要做的业务操作。

2. 直接用generateSequence，最轻量化的写法 #

如果不想额外写扩展函数，也可以直接用Kotlin标准库的generateSequence——它本身就支持：当传入的lambda返回null时，就停止生成元素。直接用它的话代码会更短：

ZipInputStream(stream).use { zip ->
    generateSequence { zip.getNextEntry() }
        .filter { it.name.endsWith(".txt") }
        .forEach { println(it.name) }
}

这段代码和你原来的while(true)逻辑完全一致，但看起来清爽多了，没有那种“无限循环break”的生硬感，完全是声明式的写法。

3. 封装成标准Iterator，兼容Java迭代场景 #

要是你需要和Java的迭代器接口兼容，或者想自己实现标准的迭代逻辑，也可以把这个“空迭代器”转成Kotlin的Iterator：

fun <T> (() -> T?).asIterator(): Iterator<T> = object : Iterator<T> {
    private var nextItem: T? = null
    private var hasNextChecked = false

    override fun hasNext(): Boolean {
        if (!hasNextChecked) {
            nextItem = this@asIterator()
            hasNextChecked = true
        }
        return nextItem != null
    }

    override fun next(): T {
        if (!hasNextChecked) hasNext()
        return nextItem?.also {
            nextItem = null
            hasNextChecked = false
        } ?: throw NoSuchElementException()
    }
}

// 用法示例
ZipInputStream(stream).use { zip ->
    zip::getNextEntry.asIterator()
        .asSequence()
        .filter { it.name.endsWith(".txt") }
        .forEach { println(it.name) }
}

这个方案稍微重一点，但胜在完全符合Java/Kotlin的标准迭代器规范，适合需要和依赖Iterator的代码交互的场景。

为什么这些方案更“Kotlin味儿”？ #

Kotlin的设计哲学就是用声明式的代码替代命令式的循环，上面的方案都把“取元素直到null”这个重复逻辑封装起来了，业务代码里只需要关心你真正要做的事（比如过滤txt文件、打印名字），可读性和维护性都更好，而且完全是通用的——不管你的那个“取元素”方法叫什么，只要它返回T?，就能直接套用。

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