前端使用typescript，后端使用C++和lua，在讨论后端下发的int64类型值如何处理时，我建议前端使用long.js，但前端说他需要用这个作key，而js没法用自定义类型作key。我回了一句“js居然没法用自定义类型作key，这么弱”，但是说完这句话，我就愣住了，貌似那里不对。
我认为任何一门逻辑完备的语言（基础的数据结构和流程控制等等），都能实现这么一个逻辑，js显然也能实现。说“无法”无非就是实现代价过大，比如需要引入其他库、修改更多的代码，运行效率更低等等原因。但我之所以会愣住，是因为当时脑中想的是“C++和lua都支持，而js这个应该这么广的语言居然不支持“，然而转念一想，lua支持任意数据类型作key，但和用自定义类型作key完全不是一码事。
首先，来看下C++中的自定义类型为key
#include <unordered_map> #include <iostream> class MyInt64 { public: MyInt64(int hi, int lo) { this->hi = hi; this->lo = lo; } ~MyInt64() { } int hi; int lo; }; class MyInt64Hash { public: std::size_t operator()(const MyInt64 &i) const { int64_t hash = i.hi; return (hash << 32) + i.lo; } }; struct MyInt64Equal { bool operator () (const MyInt64 &lhs, const MyInt64 &rhs) const { return lhs.hi == rhs.hi && lhs.lo == rhs.lo; } }; int main() { std::unordered_map<MyInt64, int, MyInt64Hash, MyInt64Equal> map; MyInt64 i1(1, 1); MyInt64 i2(1, 1); map.emplace(i1, 999); auto found = map.find(i2); if (found != map.end()) { std::cout << found->second << std::endl; // 输出 999 } return 0; }
在上面的代码中i1和i2是不同的两个变量（它们的地址不一样），但是他们的值是一样的，所以对map进行操作时，他们操作的是同一个值。而在lua中，固然可以用任意类型的变量作为key，比如
local i1 = {1, 1} local i2 = {1, 1} local map = {} map[i1] = 999 print(map[i2]) -- 输出nil
显然，这不预期的结果啊。在前后端交互的过程中，可以保证数值是一致的，但哪能保证他们的地址是一致的呢(如果能知道地址，就直接拿到变量了，还要这个map干啥)。我使用lua将近5年了，还是第一次遇到这个问题，我的第一反应是这个在元表中有一个__hash之类的吧，然而元表中有__eq，却没有__hash，那这意味着，官方是没有直接实现这一个功能的。
假如让我实现这个功能，我的第一反应是使用元表的__index和__newindex来劫持这个map的读写，但这样一来，就需要把真正的数据存在另一个table中，然后为了实现遍历，还需要重新实现__pair，那事情就变得复杂多了。这个功能虽然小众，但如果支持的话，还是十分方便的，是什么原因C++支持这个自定义hash，而lua不支持呢，这我倒来了兴趣。
网上查了一下，原来这个事情在10多年前早有定论：http://lua-users.org/lists/lua-l/2009-02/msg00000.html，总结一下，大概有以下几点原因
1. lua使用非基础类型（table、userdata等等）为key时，直接使用内存地址，这相当于没有hash函数，效率高
2. 实现__hash这个函数很容易，但是什么时候调用很难确定。最好的方案是如果存在__hash，则调用__hash，否则按原方案使用内存地址作为hash。但是这个方案会导致table的效率大幅下降。因为即使没有__hash，原来直接取内存地址这一个步骤，变成了判断是否存在元表、是否存在__hash、取内存地址三个步骤，而table是lua唯一的数据结构，包括标准库在内都是使用table，这显然会导致整个语言的效率大幅下降
3. 在第2点的基础上，即使不考虑效率问题，自定义key的mutable（可变）让整个table的维护变成无比复杂。例如
local i1 = {1, 1} local map = {} map[i1] = 999 i1[1] = nil -- 这时候map需要做什么变化？？？
当key中的数值被修改时，那__hash得到的值必定会变化，如果重新调整map中的元素hash，显然很低效，也不现实（需要跟踪i1所有值的变化，包括它的子table的子table的子table...），如果不调整，那整个hash就对不上了。C++不存在这个问题是因为C++会把key复制一份变成const，但是在lua中复制这一份table完全不现实，因为这个table可能无比巨大
4. 上面说了那么多__hash缺点，假如我不实现__hash，以现在的代码，我就能更优雅地解决问题，又何必去实现__hash
local i1 = {1, 1} local i2 = {1, 1} local map = {} -- 假设lua不支持int64，而我们需要用int64作key，那使用使用 高位_低位 这个字符串作key setmetatable(map, { __index = function(t, k) return rawget(t, k[1] .. "_" .. k[2]) end, __newindex = function(t, k, v) return rawset(t, k[1] .. "_" .. k[2], v) end }) map[i1] = 999 print(map[i2]) -- 输出999
当然我这个例子是针对自己的业务逻辑写的，并不是很通用，需要更通用的方式可以考虑自己封装，参考：http://lua-users.org/wiki/ComparisonByValue