登录成功后应立即查数据库中该用户上一次 status=’success’ 的 login_time 和 login_ip，限定 user_id、status 及 created_at < 当前时间，避免用 LIMIT OFFSET；真实 IP 需校验可信代理并过滤私有地址；IP 存储推荐 INT UNSIGNED（IPv4）或 VARBINARY(16)（双栈）；时间统一返回带时区 ISO 8601 或 UTC 时间戳。
登录成功后怎么拿到上次登录时间与 IP
得在用户本次登录完成、鉴权通过的那一刻，立刻查数据库里该用户上一次成功的 login_time 和 login_ip 字段。不是读 session，也不是靠前端传——那些都不可信。
常见错误是：把「当前登录记录」和「上次登录记录」混成一条查，或者用 MAX(created_at) 但没加 WHERE user_id = ? AND status = 'success'，结果查到的是别人的数据或失败记录。
- 必须限定条件：
user_id+status = 'success'+id < 当前登录记录 id（如果用自增主键）或created_at < NOW() - 推荐用子查询或窗口函数，避免用
LIMIT 1 OFFSET 1——分页不稳定，尤其高并发写入时容易跳过记录 - 如果数据库没存历史 IP，现在就得补：每次成功登录必须
INSERT INTO login_log (user_id, login_ip, login_time, status)
PHP/Python/Java 中读取客户端真实 IP 的坑
直接用 $_SERVER['REMOTE_ADDR'] 或 request.remote_addr 拿到的往往是反向代理（Nginx、CDN）的内网地址，不是用户真实出口 IP。
真正要的是 X-Forwarded-For 最左端那个非私有地址，但不能无脑取第一个——攻击者可以伪造该 header。
- 必须校验上游可信代理 IP（比如 Nginx 所在服务器 IP），只信任来自这些 IP 的
X-Forwarded-For - 过滤掉私有地址：
127.0.0.1、10.0.0.0/8、172.16.0.0/12、192.168.0.0/16、::1等 - Go 里可用
realip.FromHeaders，Python 可用django.utils.http.real_ip（需配置SECURE_PROXY_SSL_HEADER），Java Spring Boot 推荐用HttpServletRequest.getRemoteAddr()配合ForwardedHeaderFilter
MySQL 存 IP 用 VARCHAR(39) 还是 INET6_ATON()
存 IPv4 用 INT UNSIGNED 最省空间且可索引，但 IPv6 必须用 VARBINARY(16) 或 VARCHAR(39)；强行统一用字符串，后续查范围、排序、去重都会变慢。
别信“以后再改”，上线后改字段类型 + 迁移数据，锁表风险大，业务得停。
- IPv4 场景简单：用
INT UNSIGNED+INET_ATON('192.168.1.1')写，INET_NTOA(ip_int)读 - IPv4/IPv6 混合场景：用
VARBINARY(16)，写入前用INET6_ATON('::1')，读出用INET6_NTOA(ip_bin) -
VARCHAR(39)看似省事，但无法做 CIDR 匹配（如查192.168.0.0/16下所有 IP），也容易存重复格式（010.000.000.001和10.0.0.1被当不同值）
前端显示「上次登录时间」时区不一致问题
后端返回的时间戳如果是本地时区（如 2024-05-20 14:30:00），前端用 new Date('2024-05-20 14:30:00') 解析，会按浏览器本地时区解释，导致上海用户看到的是东八区时间，旧金山用户看到的是西八区时间——其实都是同一个瞬间，显示却差 16 小时。
根本解法只有一个：后端统一返回 ISO 8601 格式带时区的字符串，比如 "2024-05-20T14:30:00+08:00" 或更稳妥的 UTC 时间 "2024-05-20T06:30:00Z"。
- 不要返回无时区的
"2024-05-20 14:30:00"，JSDate构造函数对这种格式行为不一致（Safari 和 Chrome 解析逻辑不同） - 如果用 Unix timestamp（秒数），确保是 UTC 时间点，前端
new Date(ts * 1000)才可靠 - 展示层用
toLocaleString()或Intl.DateTimeFormat格式化，别自己拼字符串
事情说清了就结束
