PHP应用生成非人类可读交易参考号的规范实现方法咨询

嘿，我之前做支付相关的PHP应用时也碰到过类似需求——既要交易号唯一、不可读，又不能太长影响使用。你的原始方案（时间戳+邮箱）确实太直白，而普通加密又会导致字符串过长，下面给你几个针对性的解决方案：

方案1：自增ID + Base62编码（最推荐，唯一性100%） #

如果你的交易表有自增主键ID，这是最稳妥的方式。Base62用0-9、a-z、A-Z共62个字符编码数字，能把长数字压缩得很短：比如100万的ID转成Base62只有6位（L9S0wy），1亿的ID也才8位左右，完全满足短且不可读的要求。

PHP代码示例： #

function base62Encode(int $number): string {
    $chars = '0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ';
    $base = strlen($chars);
    $result = '';
    
    while ($number > 0) {
        $result = $chars[$number % $base] . $result;
        $number = (int)($number / $base);
    }
    
    return $result ?: '0';
}

// 使用示例：假设交易表自增ID是123456
$transactionId = 123456;
$referenceNumber = base62Encode($transactionId);
// 输出：3d7s

优点：绝对唯一、生成速度极快、字符串极短；缺点：参考号里不包含交易的额外信息（不过你可以把ID和交易记录关联，需要时从数据库查）。

方案2：哈希截断 + 随机因子（适合无自增ID的场景） #

如果没有自增ID，可以用「时间戳+邮箱+随机数」组合后哈希，再截断到合适长度。比如用MD5哈希（32位）取前12-16位，碰撞概率极低（对于普通业务场景几乎可以忽略），而且完全不可读。

PHP代码示例： #

function generateReference(string $email): string {
    // 组合唯一因子：精确到毫秒的时间戳 + 邮箱 + 随机数
    $uniqueString = microtime(true) . $email . random_int(1000, 9999);
    // 生成MD5哈希，取前16位
    $hash = md5($uniqueString);
    return substr($hash, 0, 16);
}

// 使用示例
$referenceNumber = generateReference('customer@gmail.com');
// 输出类似：a3f7d2k9e4b8c1x2

优点：不需要依赖数据库自增ID；缺点：理论上存在极小的碰撞概率（高并发场景建议加个分布式锁或者用Redis自增序列辅助）。

方案3：自定义二进制组合 + Base64URL编码（兼顾信息与长度） #

如果你希望参考号隐含一些交易信息（比如时间戳、邮箱标识），但又不想暴露，可以把这些信息打包成二进制，再用Base64URL编码（去掉+/=等特殊字符，更适合作为参考号），最终长度大概12-16位。

PHP代码示例： #

function generateCompactReference(string $email): string {
    // 4字节时间戳（精确到秒）
    $timestamp = pack('N', time());
    // 取邮箱MD5哈希的前8字节（16位十六进制转二进制）
    $emailHash = hex2bin(substr(md5($email), 0, 16));
    // 打包成二进制数据
    $rawData = $timestamp . $emailHash;
    // Base64URL编码，去掉末尾的=
    $reference = rtrim(strtr(base64_encode($rawData), '+/', '-_'), '=');
    return $reference;
}

// 使用示例
$referenceNumber = generateCompactReference('customer@gmail.com');
// 输出类似：MTY5NzE1MjQwM2E3ZjU4Yg

优点：隐含了时间和邮箱的唯一标识，长度可控；缺点：比Base62方案稍长一点，但依然远短于40字符的加密结果。

为什么不推荐普通加密？ #

你之前尝试的加密（比如AES）会生成较长的字符串，因为加密需要添加IV、填充等额外数据，而且加密是为了保密，而你只是需要「不可读+唯一」，用编码（Base62/Base64）就足够，既短又高效。

内容的提问来源于stack exchange，提问作者superwelling