主要目的：代码复用。也是一个合约。
一般性约束：1，不能有成员变量。2，不能有ether，函数不能payable。3，不能继承。4，不能selfdestruct。5，关于modifier，不能外部合约调用。
using关键字：本质上是一个语法糖。（语法糖：代码更加简洁，代码语义更加自然。语法盐：通过反人类的语法，让人更痛苦的写代码）。比如有一个Math的库，在一个合约中使用 using Math for uint; 表示：让库的方法跟它所操作的第一个参数绑定，成为第一个参数的数据类型的方法。这样会是的代码外观上显得更加面向对象，仅仅是编译器做了一些操作。
机制与内幕
1，库的internal方法是inline(嵌入)到调用者代码中了。不同的调用者对代码进行的复制。如果库中的方法都是internal的不会被单独处理，不会单独部署，只要有一个public方法都会被单独处理。
2，库的public方法是library单独部署为合约，然后用delegatecall调用。所以，如果library有public方法，则必然是要单独部署的(Linked Library)。如果全是internal方法，则可以不部署(Embedded Library)。
3，当library因为有public 而单独部署时，与proxy pattern相比照，都是利用另一个合约承载逻辑，但方法不用，一个利用存储布局，一个直接传递storage引用，上下文变量都保持在调用者一边。（调用者以delegatecall调用，由于library没有成员，被调用者只操作传入参数，因此delegatecall不是像proxy pattern中的那样通过兼容存储布局利用另一个合约逻辑的作用，而是通过操作storage属性的参数利用另一个合约的逻辑）。合约里的方法不能传入storage的变量。
4，library的public,external函数传入storage参数，从这一点上看，说它是普通合约并不准确。
5，调用者对单独部署的library的引用是在编译时完成，不是运行时，无法实现动态升级。
6，internal：只对调用者可见，并且内联编译；private：library内部用，对library使用者不可见（仅从可见性解释上，library类似超类）。public：对library使用者可见，但是合约要单独部署。
7，交易属性：解释为对storage类型参数的操作，而不是成员；或者解释为对调用者成员变量的操作；两者等价。
我是温驭臣，一个Solidity的开发学习者，以上是我的简单总结，如果有缺陷，希望在评论区看到您的补充。
