我们体验到了Qt model/view开发的优势，也体验到了QFileSystemModel的强大，但是Qt不可能帮我们把所有的事情都办了，QFileSystemModel也是有它的局限性的，我们来看一下它有哪些劣势。
QFileSystemModel只能代表本地文件系统
在Linux等其它一些操作系统上，都有虚拟文件系统的概念，最具代表性的虚拟文件系统就是GLib的GVfs，它现在作为gio的一部分，在GTK阵营乃至一些Qt阵营的桌面环境上都有广泛的应用。那么什么是虚拟文件系统呢？我们从想法的角度来举例——但凡非本地文件系统的文件系统，都是虚拟文件系统，而本地文件系统相信大家都非常熟悉了。
为了区分文件系统的区别，我们产生了uri这样一个概念，本地文件系统中的文件uri都是以“file://”开头的，比如根目录“file:///”，我们一般把同样文件系统文件的uri的开头部分称之为“uri-scheme”，那么简单来说，虚拟文件系统就是uri-scheme不是“file://”的文件系统。
对于QFileSystemModel来说，它的根目录为“/”，换而言之，它只是代表“file://”这个uri-scheme，在我们的桌面环境中，还有更多的虚拟文件系统及其“文件”，比如我的电脑“computer:///”，回收站“trash:///”，网络“network:///”，最近“recent:///”，远程服务器22端口“sftp://xx.xx.xx.xx”等等，这些虚拟文件系统的文件数据表示是QFileSystemModel在设计层面上所欠缺的。
QFileSystemModel没有太多扩展空间
作为一个成熟的Qt的API，QFileSystemModel确实没有太多的扩展空间，这可能也是和它的功能过于复杂和强大有关（即使它有1中的局限，但是我至今也没有看到过比QFileSystemModel更强大和高效的Model了）。因为这个原因，往往QFileSystemModel实用的场景特别少，反而是作为教材的范本出现的频率特别高。我想，如果Qt能够在6.0将QFileSystemModel的作用域扩展到本地文件之外，对于Qt来说绝对是一种升华（QFile可能需要转变为以QUrl为主要的构造参数），当然，我们也不能够强迫一个主打跨平台和图形开发的开发工具具备那么完善的底层功能，而且哪怕在它还没有这些功能的时候，我们也不可能放弃用Qt进行开发就是了。针对特定平台的条件，我们虽然无法直接使用Qt现有的Model进行非实验性质的开发，但是仍然可以在qt的model/view编程下做足够多的文章，下面我们来看一下当官方提供的model不能够满足我们的要求时，我们怎么样开发自己的model。
