优先用 microsoft.visualbasic.fileio.textfieldparser 解析 csv，它正确处理引号、换行、空字段；json 大文件查询应使用 jsondocument.parse 而非 jsonconvert.deserializeobject；csv/json 响应超 200ms 或需多表/分页/并发写时，应迁移到 sqlite。
直接用 读 CSV 看似简单，实际会崩在带换行符的字段（比如 Excel 导出的备注列里有回车）、中文乱码、逗号嵌套等场景。它只是按行切，完全不管 CSV 的 RFC 4180 规则。
实操建议：
- 优先用 不合适——那是 SQL Server；这里该用 + ？不对，太重。轻量级选 （别被命名劝退，C# 项目可直接引用 NuGet 包，稳定且处理引号/换行/空字段都正确）
- 如果必须手写解析，至少用 配合状态机，而不是 —— 后者在 这种数据上直接错三列
- 编码问题高频：Windows 记事本存的 CSV 默认是 或 ， 默认用 ，BOM 会被当内容；显式传 或 更可控
把几 MB 的 JSON 当“数据库”查，一上来就 ，内存暴涨、GC 频繁，查一次卡两秒。这不是反模式，是典型误用。
实操建议：
- 小文件（System.Text.Json 的 没问题，类型安全又快
- 中大文件（>1MB）或只查部分字段：改用 + 导航，它只解析 JSON 结构树，不 new 对象，内存占用低 60% 以上
- 想支持类似 SQL 的查询语法？别自己写解析器。用 库配合 转 ，能写 这种字符串条件，但注意：字段名大小写要和 JSON 一致， ≠
CSV/JSON 当数据库，本质是把磁盘 I/O 当查询引擎用。查一次开一次文件、全扫描、没索引、没事务——这些不是“功能缺失”，是设计定位决定的。
实操判断点：
- 单次查询响应超过 200ms（比如 10 万行 CSV 里 查某 ID）→ 该上
- 需要多表关联、分页（）、模糊匹配（）→ CSV/JSON 基本不可行
- 并发写入：两个进程同时 写同一个 JSON，大概率文件损坏；而 的 WAL 模式天然支持多线程写
- 迁移成本极低：NuGet 装 ，把原 CSV 用 批量 INSERT 进 文件，后续代码只需改连接字符串和 SQL，业务逻辑几乎不动
即梦Ai 教程
很多人把 从文件加载后，写 就以为是“高效查询”。其实这是纯内存遍历，复杂度 O(n)，且每次调用都重新扫描。
关键差异：
- 在内存集合上执行，无法跳过无关行；而 SQLite 的 可走索引（如果建了）
- JSON 中用 做比较前，先确认字段存在（），否则抛 ，不是所有 JSON 行都有
- CSV 场景下，如果反复查同一列，别每次都 —— 先用 解析成对象列表，再用 LINQ，否则拆分开销比查询本身还高
文件当数据库，最易被忽略的是“查询意图”和“物理存储”的错配：你想要索引、缓存、并发控制，但文件系统只提供字节流。这点不认清，优化永远在边缘打转。
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请联系我们举报，一经查实，本站将立刻删除。
发布者：全栈程序员-站长，转载请注明出处：https://javaforall.net/263747.html原文链接：https://javaforall.net
