Dartz的Either是必要选择还是个人偏好？Flutter新手技术疑问

1. Dartz是更优选择还是仅为部分人的偏好？ #

没有绝对的“更优”，完全取决于你的场景和团队约定：

• Dartz的Either这类工具能让异常处理更显式——你从类型签名就能一眼看出函数可能返回错误，不用靠注释或文档，这种风格在纯业务逻辑层能让代码更严谨，适合追求函数式编程风格的场景。
• 但Dart原生的try-catch、Future.onError更贴合语言本身的OOP特性，学习成本更低，在小型项目或快速迭代的场景下，原生写法反而更高效。
  简单说：如果团队统一用函数式风格，或者你需要更严格的错误追踪，Dartz是好选择；否则原生写法完全够用，只是不同偏好而已。

2. 为何很多人十分反感OOP？ #

不是反感OOP本身，而是反感滥用OOP的情况：

• 比如为了“符合OOP规范”强行套复杂的继承层级，明明几行能搞定的逻辑，硬拆成一堆抽象类、接口，导致代码臃肿难读；
• 还有过度依赖设计模式，把简单问题复杂化，最终项目变成“面向设计模式编程”而非“面向问题编程”；
• 另外，对比函数式编程的简洁、无副作用特性，一些糟糕的OOP代码会显得冗余、难以维护，这才让部分人产生“反感OOP”的错觉。实际上OOP在UI开发、状态管理这类场景下依然是非常实用的——比如Flutter的Widget本身就是OOP的典型应用。

3. 新手使用此类库改变语言风格、规避原生代码特性是否有益？ #

不建议一开始就这么做，理由很简单：

• 你得先吃透Dart/Flutter的原生特性——比如Future的异步逻辑、try-catch的异常处理机制，这些是你理解整个语言运行逻辑的基础。如果跳过原生直接用Dartz，你只会“抄代码”，却不知道Either解决了原生写法的什么痛点，遇到问题也很难排查。
• 等你对原生特性足够熟悉，再去尝试Dartz这类函数式库，这时你能清晰感知到两种风格的差异，也能合理判断什么时候该用、什么时候不该用。

内容的提问来源于stack exchange，提问作者Magdy Samy