Base62编码不能直接用base64.b64encode，因其含URL不安全字符+、/、=；Base62使用0–9A–Za–z共62个URL安全字符，需自定义实现并注意字符顺序、负数处理及非法输入校验。
Base62 编码为什么不能直接用 base64.b64encode
因为 base64.b64encode 产出的是含 +、/ 和 = 的字符串，这些字符在 URL 路径里要么需要编码（变成 %2B 这类），要么被 Web 服务器拒绝解析。短链接必须“即写即用”，路径段得是安全字符。
Base62 的字符集是大小写字母加数字（0–9A–Za–z，共 62 个），全部可直接出现在 URL 中。自己实现时要注意顺序：通常用 0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz，别把 O 和 0、l 和 1 搞混——用户手输时容易错，但编码逻辑本身不处理歧义，得靠前端或生成策略规避。
常见错误现象：
• 用 base64.urlsafe_b64encode 后截掉 =，结果出现 - 或 _ —— 这不是 Base62；
• 字符表顺序错乱，解码时高位/低位算反，导致 ID 错位；
• 对负数 ID 做 Base62（比如数据库自增从 -1 开始），没做符号处理，直接报错或产出非法串。
实操建议：
• 编码函数只接受非负整数，输入前强制 abs(int(id)) 或抛 ValueError；
• 字符表定义为常量 BASE62_CHARS = "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz"，别拼接或动态生成；
• 解码时遇到非法字符（如空格、中文、!）立刻返回 None，别静默替换。
立即学习“Python免费学习笔记（深入）”；
Django / Flask 里怎么让 /abc123 跳转到原始 URL
关键不是“重定向”，而是“路由捕获 + 数据库查 + 302 返回”。短链接路径是变量，不是固定接口，所以不能写死 path('abc123/', ...) 这种。
使用场景：
• Django：用 path('<code>/', views.redirect_view)，code 是任意长度的字符串；
• Flask：用 @app.route('/<code>')，注意别漏掉斜杠，否则 /abc123/ 和 /abc123 被当成两个路由；
• FastAPI：用 @app.get("/{code}")，同样需处理末尾斜杠一致性。
容易踩的坑：
• 忘记对 code 做长度或字符校验，攻击者可能传入超长随机串打满数据库查询；
• 查不到记录时返回 200 + 页面提示，而不是 404 —— 搜索引擎会误收录失效链接；
• 用 301 永久重定向：一旦原始 URL 改了，缓存无法更新，用户永远跳不过去。
实操建议：
• 在视图开头加粗粒度校验：if not re.fullmatch(r"[0-9A-Za-z]{4,12}", code): return HttpResponseNotFound()；
• 查询用 .filter(code=code).values_list("original_url", flat=True).first()，避免 ORM 加载整行；
• 重定向用 302，响应头加 Cache-Control: no-store，防止 CDN 缓存跳转逻辑。
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
短链接 ID 怎么从数据库自增转成 Base62 码而不暴露总量
直接用主键 ID 编码，等于把数据库当前记录数“明文广播”出去——别人访问 /0、/1、/2 就能刷出所有链接。必须脱敏。
参数差异：
• 方案 A（推荐）：新增一个 short_id 字段（bigint 或 UUID），插入时用 secrets.randbelow(10**12) 随机生成，冲突则重试 —— 简单，但有概率撞，需加唯一索引和重试逻辑；
• 方案 B（更稳）：用发号器（如 Twitter Snowflake 变种），服务启动时分配机器 ID，本地递增生成带时间戳的 ID，再 Base62 —— 不依赖 DB 主键，但要维护发号逻辑；
• 方案 C（伪随机）：对自增 ID 做异或+移位（如 (id ^ 0xdeadbeef) * 11111111），再 Base62 —— 仍可逆向推总量，仅防小白遍历。
性能影响：
• 随机生成 + 唯一索引冲突重试，在 QPS > 100 时可能明显拖慢写入；
• 发号器方案读写都快，但多实例部署时得协调机器 ID 分配；
• 异或方案最快，但安全性最低，仅适合内部工具。
实操建议：
• 初期用方案 A，加 unique_together = ("short_id",) 和最多 3 次重试；
• 生成后立即 save()，别等事务结束才编码，避免并发写入重复；
• 日志里记录原始 ID 和生成的 short_id，方便后续审计或迁移。
上线后发现短链接打不开，优先查哪几处
不是代码问题，往往是部署链路上的隐性断点。
常见错误现象：
• 浏览器地址栏显示 https://yoursite.com/xyz，但实际请求被 Nginx 重写成 /index.html?/xyz（Vue Router history 模式干扰）；
• WSGI 服务器（如 Gunicorn）配置了 --forwarded-allow-ips="*"，但反向代理没传 X-Forwarded-For，导致 request.build_absolute_uri() 生成 HTTP 链接而非 HTTPS；
• 数据库连接池耗尽，查 code 时超时，视图没设 timeout，整个请求卡住 30 秒才 504。
实操建议：
• 在重定向视图开头加一行日志：logger.info("redirecting %s → %s", code, original_url or "(not found)") ，确认是否走到这步；
• 用 curl -v https://yoursite.com/abc123 看真实响应头，重点检查 Location 是否正确、状态码是不是 302；
• 登服务器跑 python manage.py shell，手动调 decode_base62("abc123") 和 Link.objects.filter(short_id=...).first()，验证编解码和查询通路；
• 所有外部依赖（DB、Redis、HTTP 客户端）都加超时：数据库 timeout=3，HTTP 请求 timeout=(3, 3)。
最常被忽略的是反向代理的 header 透传和静态文件服务器对短链接路径的拦截。事情说清了就结束。
