@GuuJiang 不小心按错发出来了，接着写
参见我在 https://v2ex.com/t/790199#reply32 里的回答，这里我多花点篇幅争取把这个问题一次性讲清楚
首先准备点开胃菜，当我们有一个类型为 A 的引用 a 和一个类型为 B 的对象 b ，什么情况下 a = b 这个语句是合法的？答案就是当 b instanceof A 的时候，这就是 OOP 的几大基石之一的里氏代换原则，也就是说当需要一个类型 A 的场合，类型 A 及其子类都是可以接受的，这也就是为什么 instanceof 运算符的反射版本名字叫作 isAssignableFrom
对于简单类型来说，任给两个类型 A 和 B ，判断 A 和 B 之间是否具有 instanceof 关系是很简单的，直接看两个类的定义就行，如果类的定义里有直接或者间接的 extends 或者 implement 关系，则具有 instanceof 关系，否则不具有
但是到了范型的世界里，问题就开始变得复杂起来了，如果 B 是 A 的子类，那 List<A>和 List<B>这两个类型里，谁是谁的子类？答案是不具有 instanceof 关系，这就叫做 invariant ，但是 invariant 的类型系统功能比较弱，很多想要的功能实现不了，这就需要引入另外两种关系，即协变(covariant)、逆变(contravariant)
回到我最开始说的，在关于范型约束的这个问题上，很多人存在一个误解，或者曾经存在这个误解，导致总是觉得有哪里不对，怎么也圆不回来，再听完别人说什么协变逆变、PECS 等以后就更懵了，而只要这个误解一消除，范型约束瞬间就变得异常简单，没有任何不理解的地方，这个误解就是“认为 List<? extends T>和 List<? super T>里的 extends 和 super 约束的是类型 T 和这个 list 里能够放的对象类型之间的 instanceof 关系”，而这个误解的正确答案是，把 List<? extends T>这个类型整体视为类型 A ，把 List<? super T>这个类型整体视为 B ，然后现在有若干的类型 C 、D 、E……，都是 List<X>的形式，其中的 X 为某个具体类型，extends 和 super 真正约束的是 A 与 B 和 C 、D 、E 之间的 instanceof 关系，换句话说就是，有一个 List<? extends T>类型的引用，这个引用能接受什么类型的 list 对象，有一个 List<? super T>类型的引用，这个引用能接受什么类型的 list 对象，这才是范型约束的真正含义
其实我个人并不喜欢 Java 的这个语法，应该说这个误解这么普遍，可能跟 Java 选择的这个语法有一定的关系，而相比起来 c#和 scala 在这方面的语法就会稍好一点，因为 Java 的这个语法给人一种错觉，就是 List<T>、List<? super T>、List<? extends T>是三个不同的类型，当然严格说起来它们确实是三个不同的类型，但是从某种意义上来说，可以认为它们都是 List<T>，但是具有不同的 variance 属性，换句话说，如果换成下面的伪代码可能会更好理解

这可以算得上是一个月经问题了，和其他另外几个问题一样，属于里面有一个弯转过来了就一切迎刃而解，转不过来就始终似懂非懂

@inprtx 你没有理解 op 的目的，结合着 op 的上一篇帖子看，是利用墙内部不同模块之间的优先级，所以人为制造一个满足被墙条件的场景是必需的

对 b 建立 AC 自动机

@cpstar 帮 op 断下句
两个(((等于 1 的位)不重叠)的二进制数)

是个典型的不顾适用条件滥用二级结论的例子
首先，月薪的个人所得税是分段函数，但是为了简化分段函数的计算，所以总结出了速算扣除数，用速算扣除数计算和直接计算分段函数是等价的
但是到了年终奖的计算时如果仍然想继续使用速算扣除数的话，它的值应该 x12 ，这样背后对应的仍然是一个合理的分段函数，而把计算月薪时的速算扣除数机械地搬过来是没有任何道理的，因为这个速算扣除数再还原回原本的函数就会得到现在的那个锯齿状的函数
生活中有很多这样的例子，为了计算或者记忆简便，人们总结出了很多的二级结论，但是随着时间的推移，人们慢慢地只记二级结论，而完全忽视了背后的本质内容，并且在本质结论不适用的场景强行套用二级结论，自然就得到了错误的结果，类似的例子有极限计算里的等价无穷小

@xiaoyanbot 故名思义就是不填充，但是有个限制就是数据必须正好要是 16 的整数倍，所以通常都不会使用这个模式的，而是使用 pkcs5 填充，因为你要求得到和你给的 go 示例里完全一致的结果，所以在这个例子里只有 nopad 才能满足，但是真正用于通用场景的话还是应该使用 pkcs5 填充

顺便附上解密
echo -n 319d4fa655ed543b4aa0d1efdc3619d8 | xxd -r -p | openssl enc -aes-256-ecb -d -nopad -K 746869735f6d7573745f62655f6f665f33325f627974655f6c656e6774682121

不要自己发明概念，就是标准的无填充 aes-256-ecb 而已
echo -n "This is a secret" | openssl enc -aes-256-ecb -nopad -K 746869735f6d7573745f62655f6f665f33325f627974655f6c656e6774682121 | xxd -p

用合适的工具去做合适的事，既然是 json 结构，就要用 json 的方式去处理，使用正则表达式属于歪门邪道，会有很多很多的特殊情况，比如 value 里面有个转义过的双引号怎么办，就算你不断地针对每一种特殊情况去打补丁，最后这个正则表达式也会变得复杂无比

@Buges
@ysc3839
所以我说这个误解是多么的典型，因为会犯这个错误的人不少，类似的问题随便动动手就能搜到一大把
https://stackoverflow.com/questions/3391242/should-i-hash-the-password-before-sending-it-to-the-server-side
你一直在说撞库，请问防止撞库的手段是传输 hash 吗？不是，是存储 hash ，而传输 hash 的行为大大降低了存储 hash 的意义，极端情况下降为 0 ，你可以继续坚持自己的观点并在实际项目中使用前端 hash 并传输，但是麻烦告知下这样的项目地址以供避雷

@Buges 我从来没有否定存储 hash ，我否定的是前端 hash 并传输，你举的例子恰恰又一次证明了我的观点，如果全世界都前端 hash 并传输(假设在不加盐的前提下)，存储 hash 变得毫无意义

@Buges 前端 hash 是安全问题中最最最典型的一个只知其一不知其二而导致的误解，首先要知道之所以后端存储 hash ，目的是防止被脱裤后泄露密码，但是如果使用方式是前端 hash 并传输，那么脱裤者根本就不需要关心密码明文是什么，此时的 hash 就等于明文，使得后端存储 hash 变得形同虚设

@ershierdu 是不太大，也就 6670903752021072936960 种而已:doge:

@sunny352787 你自己再想想

@sunny352787 左移操作等于 x2 和大小端存储之间没有任何联系

点进来之前的我😏
点进来之后的我🥲

mutex

@icyalala 这几个统统都不是编程术语，而是数学术语