开场白
本文力求少用科班学究气息的名词、描述、概念、定义、定理、公式。如果那样的话 就不用我来这里显摆，因为这些词语大可在更高水平的教科书、学术文章里读到。本文不是论文，不是（也的确没水平）去推导某种结论，也不是发表论文的地方。
我也不想用某程序语言特有的规则、代码 来表达和讲解文义，否则让人搞不清那些概念和理论 与程序语言 究竟谁是鸡谁是蛋；我也不是在通过MONAD讲解语言特征、编程架构、设计模式和实现方法。
虽说数学是现实世界的抽象，但如果遇到诸如“为啥矩形面积等于边长相乘”那样的问题，我就搬出一堆数学公式、或放出一通程序代码 以此证明就应该那样运算，这真的表明 我明白了面积算法的本来含义吗？一言不合就亮公式、撸代码 这不是本文要的风格。
某大咖神教思想语录：“Monad 不就是个自函子范畴上的幺半群（A monad is just a monoid in the category of endofunctors）”
这句话之所以能作为劝退哲学的典范，就在于——对于其智力和学术水平还达不到能懂得“自函子、范畴、幺半群”之类阳春白雪 的人，Monad无异于对牛弹琴！
正题
看了众多Monad相关的文章或介绍，基本得到这样的理解：
①将一个包裹（文绉绉地称之为“容器”）C1里的值a提取出，②运用一个普通函数fa去处理这个值，得到了新值b，③把b再包裹（到C2）。于是原来那个只处理包裹C1里面值的函数fa 变身成了能反映这两个包裹之间映射关系的“函数”fmap。
该包裹就是科班行话中的 “范畴”或“高阶类型——类型类”——如果里面的值属于类型T，则包裹就是T的类。有的文章管它叫“Context”，本文引用的示意图就用了这个称谓。
大部分文章都用Maybe（如Haskell）或Option（如ML，JAVA等）类型作为包裹的举例，但其实列表、字典等基于元素的集合类型 也同样属于这种高阶类型。
如果类比OOP，包裹好比封装，上述“变身”过程fmap就是个Functor，两者结合构成的class就是Functor类。
虽然用OOP类比Functor不算严谨，会让某些FP建制派感到不爽，但对于数量更广大的熟悉OOP的人来说 会更通俗易懂。
广义地理解：两个数据类型（可视作对值的包裹）C1和C2，以及对它们的彼此加以变换的方法Functor结合在一起的类都可称作Functor类(类型的类)，比如 某类型通过列表构造器 形成 以该类型的元素所组成的列表类型，则元素类型、列表类型 加上它们的map、filter等函数 即可以组合成一Functor类。
“所谓函子就是表示两个范畴的映射”这句话表达的就是这层意思。
有人说：普通函数Function是反映两个类型之间的变换(映射)关系，针对的是特定类型；而函子Functor是针对范畴——亦即类型的集合——的映射关系。我不想纠缠于这两者的学术定义的细枝末节——何谓特定类型？何谓类型的集合？分界点在哪里？反正在计算机语言里，除了整数、浮点数、单字符等少数几个基本类型（有的语言称之为“标量类型”），其它全都是复合而成的集合类型，连字符串String都不能算基本类型（比如F#和C#就把String处理成单字符的序列，就是集合类型）。真要矫情也可以说：正整数是一个基本类型，负整数又是另一个基本类型，整个整数就是两者的“集合类型”。非要划分清楚谁是特定类型 谁是集合类型？可不可以再说：奇数是一个特定类型、偶数是另一个……那样还有完没完？！
所以我认为：普通函数function就是更广义的函子Functor的特例。
由于Functor类的“变身”方法接收的是个包裹，所以要给这个Functor类加上 能接收一个常规（未包裹的）值的接口——这个接口负责给输入的常规值打包，“塞入”变身方法。于是完整的流程就是Monad。
Haskell用<$>表示Functor，>>=表示Monad，其符号本身并不能给我们以上这些概念及其关系的细节。有人说“具有>>=操作的数据类型就叫做Monad”，这恐怕把因果、基本原理与具体实现的关系搞反了吧——好比他是在说“面积能用边长相乘的 就叫矩形”。
据说，“Monad始终是和副作用相关的，Wadler 大神那篇 monads for functionaly programming讲monad开篇就一直在重复monad的动机是为了让pure language有impure language的特性”、“Monad之所以被发明出来就是为了副作用和 做到destructive inplace update”。
如果前面对Monad的理解基本正确，就生出问题：Monad跟纯函数（引用透明、无副作用）有什么瓜葛？或者问：Monad为何能够实现正统纯函数不具备的有状态和副作用？或者问：在保持纯函数的前提下 为何通过Monad可解决状态保留和转移？
纯函数只要输入相同 就会输出相同结果。但纯函数又不能保留状态，同一个“变量”在其作用域的任何位置和任何时候 其值保持不变，所以不能指望 可变值的全局变量或（如闭包里的）函数自含变量 来保存不断变化的状态。为了像不纯函数——如随机数生成函数——那样 每次调用（即便相同输入）都会输出不同结果，每次调用就必须给它不同的输入，以影响函数输出不同结果，即靠函数参数 把上次调用的结果作为“种子”传递给下一次的调用，借以产生新的不同结果。因为没有地方可以“暂存”这个种子，所以需要让这个种子一直在“路上奔跑”，“路”上的一系列函数（很可能就是同一函数的重复调用）以参数和返回形式像接力棒似的让其不停地“穿过”，甚至不惜特意加入循环/迭代（如Erlang）只为能持久保持。这就陡增了程序的复杂性和工作量。为了减轻视觉负担和维护这些穿梭的“状态”，Monad就粉墨登场了。
根据前面理解的Monad流程：有个接口能接收一个常规（未包裹的）输入值a，该值就是“种子”的最初值。
然后有个Functor方法（就是那个fmap），依靠能对种子进行运算和处理（为了将种子不断变化呀）的普通函数fa 将包含a的包裹“变身”成包含种子输出值b的包裹。如果种子要穿越一系列函数，每个Functor类接受上一个Functor类传来的包裹，“变身”得到的新包裹再传给下一个Functor类。于是种子着包裹完成了在各个函数的穿越（Threading State）。
为什么要以包裹而不直接让值本身去穿越？
输出与输入未必是相同类型，不同函数会各自有不同的进出参数的类型的要求。有时函数运算的结果会有多个“可能”的值，如出错后的无效值None或Nothing。用统一形式的包裹可以让传递的种子具有 犹如快递和邮政部门那样的统一包装，打包、解包的方式也能统一。这将大大简化写代码的工作量，唯一需要做有区别的事就是绑定不同的普通函数。
这种统一格式的作业流程不是跟管道（FP的另一种奇巧淫技）或链式调用很像嘛。我认为确实是，两者异曲同工。前面已经说了：元素类型通过列表构造器所生成的列表类型 也是Functor类。Monad看上去(Bi Ge)更高级些。。
有了统一类型Context这根接力棒，各函数之间就是简单的数据流接力赛——函数复合。
Monad的好处是（包括但不限于）：不会像函数式的管道那样 每个函数都要写一遍打包和解包的代码，那会很繁琐 很啰嗦。
用了Monad，这个打包和解包的代码（因为都基于同样的包裹类型）可以一次性写在通用的（将函数绑定给各个Functor类）的绑定代码里，而各个函数只需关注纯粹处理值的特定逻辑，函数复合也将很简洁。
用无副作用的纯函数模仿有副作用的不纯函数的效果 是Monad重要应用场景之一。
声明：文中的示意图都取自网络分享资料。