有同样想法，想问下大兄弟 UI 是怎么解决的

@zhenjiachen 同意，简单直接，不过我这需求有些不一样

@IamNotShady 有点疑问，我在线（ http://encode-base62.nichabi.com ）转了下，发现和这个库的结果不一样呢

@troywinter 感谢分享，我觉得我的问题应该变成暴露用户 id 是否有隐患。

根据这里（ https://stackoverflow.com/questions/3629134/should-i-expose-a-user-id-to-public ），一般应用直接暴露 id 应该没事，我看好多网站也是暴露了的。当然具体情况具体分析，我这里的需求可能不能直接暴露，因为 id 和兑换码联系了起来，要防止被枚举。
我的想法是这样，还是简单些做，用户注册的时候用 snowflake 生成的 id 做一遍 hash 或 encode，这样至少不是直接暴露 id，然后存到 db 做个 index， 兑换时（用户的分享码就是别人的兑换码，需求是这样 = =）再用这个码去找是否存在。
不知这样妥否，有无可以优化的地方。

@jinhan13789991 想要已经现成的 app，哈哈

@qwertyegg 嗯，这需要 app 自身支持嘛， 我是需要一个第三方 app 来配置拦截 schema，指定需要跳转的 app

@ryV60s 只是 id 用吗? 我这里需求是分享码呀,要在个人信息中返回, 不会每次返回都算一遍吧(不考虑缓存的话)

@IamNotShady 咦, 这倒第一次听说, uuid 不是规范吗? 这么指定长度呢? 不是截取吧?

@LeeSeoung 那个感觉不太符合这场景, 而且也没必要过度设计

@ryV60s 看来下感觉不错, 我看文档说不用每次存 db, 通过每次加解密, 想问下你们项目使用也是类似需求吗? 是这么处理的

@IamNotShady @momocraft
再谢, 但 uuid 有些过长了, 有什么好的方式变短些并保证唯一性吗?

@Mithril 嗯, 但为什么要对称加密呢? secure hash 呢?

@IamNotShady 嗯, 如果这个 id 同时是用户在系统中的唯一标识, 会有什么设计上的缺陷吗?

@momocraft 有点懂了,是否是因为 snowflake 的生成是可预测的呢?就有可能被枚举来使用

@momocraft 谢谢, 但为什么会好些呢? uuid4 我看是降低碰撞, snowflake 应该是能完全避免碰撞吧(1s 内多少次)

@KunMinX 谢谢分享，其实这里就像求个解决方案，不过原理更好不过了，谢谢了

@FrankHB 有道理

@jinhan13789991 play store 没搜到呢