从实践的角度来看（总结了之前许多回答和相关文章中所说的内容），在我看来，monad的一个基本“目的”（或有用性）是利用递归方法调用（即函数组合）中隐含的依赖关系（即，当f1调用f2调用f3时，f3需要在f1之前的f2之前求值），以自然的方式表示顺序组合，特别是在惰性评估模型的上下文中（即，作为一个普通序列的顺序合成，例如C中的“f3（）；f2（）；f1（）；”），如果你想到f3、f2和f1实际上什么都不返回的情况（它们作为f1（f2（f3））的链接是人为的，纯粹是为了创建序列），那么这个技巧就特别明显了。

当涉及到副作用时，这一点尤其重要，即当某些状态被改变时（如果f1、f2、f3没有副作用，那么它们的求值顺序无关紧要；这是纯函数语言的一个很好的特性，例如能够并行化这些计算）。函数越纯越好。

我认为，从这个狭隘的角度来看，monad可以被视为支持惰性求值的语言的语法糖（只有在绝对必要时才求值，遵循不依赖于代码表示的顺序），并且没有其他表示顺序合成的方法。最终的结果是，“不纯”（即确实有副作用）的代码段可以以命令式的方式自然呈现，但与纯函数（没有副作用）完全分离，纯函数可以延迟求值。

正如这里所警告的，这只是一个方面。

如果您曾经使用过Powershell，Eric描述的模式听起来应该很熟悉。Powershell cmdlet是monad；功能组成由管道表示。

杰弗里·斯诺弗对埃里克·梅杰的采访更为详细。

我分享了我对蒙纳斯的理解，这在理论上可能并不完美。Monad是关于上下文传播的。Monad就是，您为某些数据（或数据类型）定义一些上下文，然后定义该上下文将如何在整个处理管道中与数据一起传递。定义上下文传播主要是定义如何合并多个上下文（相同类型）。使用Monads还意味着确保这些上下文不会意外地从数据中剥离。另一方面，可以将其他无上下文数据带入新的或现有的上下文中。然后，可以使用这个简单的概念来确保程序的编译时正确性。

在OO术语中，monad是一个流畅的容器。

最低要求是类＜a＞的定义，它支持构造函数Something（a a）和至少一个方法Something<B＞flatMap（函数＜a，Something<B＞＞）

可以说，monad类是否有签名Something＜B＞work（）的方法来保存类的规则——编译器在编译时在flatMap中烘焙。

为什么单子有用？因为它是一个允许保留语义的可链式操作的容器。例如，可选<？>为Optional<String>、Optional<Integer>、Optional<MyClass>等保留isPresent的语义。

作为一个粗略的例子，

Something<Integer> i = new Something("a")
  .flatMap(doOneThing)
  .flatMap(doAnother)
  .flatMap(toInt)

注意，我们以字符串开头，以整数结尾。很酷。

在OO中，这可能需要一点努力，但Something上的任何方法如果返回Something的另一个子类，都符合返回原始类型容器的容器函数的标准。

这就是保持语义的方式——即容器的含义和操作不会改变，它们只是包装和增强容器内的对象。

monad是一种封装值的数据类型，本质上可以对其应用两个操作：

返回x创建封装x的monad类型的值m>>=f（读作“绑定运算符”）将函数f应用于monad m中的值

这就是monad。还有一些技术问题，但基本上这两个操作定义了monad。真正的问题是，“monad做什么？”，这取决于monad-列表是monad，Maybes是monad；IO操作是monad。当我们说这些东西是monad时，这意味着它们具有返回和>>=的monad接口。

典型用法中的Monad在功能上等同于过程编程的异常处理机制。

在现代过程语言中，在一系列语句周围放置一个异常处理程序，其中任何语句都可能引发异常。如果任何语句引发异常，则语句序列的正常执行将停止并转移到异常处理程序。

然而，函数式编程语言在哲学上避免了异常处理特性，因为它们的“goto”性质类似。函数编程的观点是，函数不应该有“副作用”，比如中断程序流的异常。

实际上，由于I/O的原因，在现实世界中不能排除副作用。函数式编程中的monad用于处理这一问题，方法是获取一组链式函数调用（其中任何一个都可能产生意外结果），并将任何意外结果转换为封装数据，这些数据仍然可以安全地通过剩余的函数调用。

控制流被保留，但意外事件被安全地封装和处理。