项目介绍 閾界档案室是一个针对异常现象爱好者开发的一个网站。收集全世界各类异常事件的资料。这些“异常事件”包括但不限于： 各类刑事案件 各类灵异事件 各类失踪事件 唯心主义的迷雾，唯物论者的悬崖

希望对缅甸不了解的朋友可以读一读。 从被西方世界殖民，到日本的屠杀暴行。从国家无休止的内战，到毁灭性的自然灾害。缅甸这个国家背负了一个国家所能遭受的几乎所有的不幸，甚至和旧中国有几分相似。除此以外，现在一些中国人趁着缅甸政治局势的动荡，中央对边境管辖的局限，到缅甸北部搞电信诈骗。这本不是缅甸人民的所作所为，也被扣上了一个危险国家的帽子。国内不明真相的网民们跟风吆喝，似乎把缅甸描述成了一个地狱，给它贴上了所有黑色的标签。 这就像夜晚一个村子里的恶霸逃了出来，到另一个村的边境路上坑蒙拐骗路自己原住村的居民。坑蒙拐骗得手了之后就藏起来。大家不讨论怎么铲除村里恶霸，而是对另一个村庄的所有人们恶语相向。这失智的群众，恶臭的三观，离谱的操作，荒诞的狗血情节。 缅甸人能够修好多座大金塔，每个人都能参观。仰光的大金塔的修建更是用了数十吨的黄金，塔顶的伞盖镶嵌着大量的宝石。按黄金的最近翻倍价格，如果缅甸人真如大家贴的标签那样利欲熏心，坑蒙拐骗，无法靠近，想必早大金塔被当地的窃贼逐渐磨平，甚至被出卖。作为信奉佛教人数比例最高的国家之一，缅甸人信仰的佛法，佛道，对佛经的理解，早已是毕生必须经历的修行。对佛的侮辱，甚至甚过违犯法律。军政府在当地的统治，军阀在各地的割据，可以自己改法，吸血压榨自己的人民，枪毙侮辱军阀的百姓，但是唯独不能摧毁每个人心目中的释迦牟尼。 请你不要被大数据的推送、夸张的短视频被遮住了眼睛，也别忘了去倾听那些沉默却坚定的声音。缅甸并不是只有战争、诈骗与苦难，她也有善良、虔诚与坚韧。这个国家的光亮，可能微弱，甚至你从抵达仰光机场的飞机向下俯瞰也不见几处灯火，但它的希望始终没有熄灭。每个缅甸人的内心和大家一样朴素，在乎的是自己的下一餐是否是美食，天冷了自己的孩子今天有没有受凉，商店里的牛奶有没有打折，以及明天，是不是会变得更好。 我相信不管缅甸会在未来遇到多大的困难，她总会再站起来。一个国家甚至一个民族的坚强，不在于她遭受到了多么毁灭性的打击，而是在于她总是能在最恶劣的环境下抬起头来，面向阳光，茁壮成长。

长相失败， 化妆无奈。 皮黑耐晒， 口音奇怪。 腿粗缺钙， 不会做菜。 如果被爱， 纯属意外。

📥下载MSCZ格式曲谱 📥下载PDF格式曲谱

你理解这段代码吗？ do { oldseed = seed.get(); newseed = (oldseed * ...) & mask; } while (!seed.compareAndSet(oldseed, newseed)); // ← CAS 第〇层：先搞懂"变量"在多线程里的危险 假设有一个变量 seed = 100，两个线程同时想改它： 线程A：读到 seed=100 → 算出新值 200 → 写回 seed=200 线程B：读到 seed=100 → 算出新值 300 → 写回 seed=300 问题来了——两个人都读到了 100，各算各的，最后谁写得晚谁赢。A 的结果被 B 覆盖了，A 白干了，而且程序根本不知道出错了。 这就是经典的 线程安全问题。 第一层：解决办法有两条路 路线一：悲观锁（synchronized） → "我先把门锁上，别人别进来" → 安全但慢（别人要排队） 路线二：乐观锁（CAS） → "门不锁，但我写之前验一下，被人改了我就重来" → 快但可能要重试 你这段代码走的就是 路线二。 第二层：什么是 CAS？ CAS = Compare And Set（比较并设置），三个参数： CAS(内存地址, 我期望的旧值, 我想写入的新值) 它做的事用大白话说： “我记得这个值是 42，如果现在还是 42，就帮我改成 77。如果不是 42 了，说明有人动过了，啥也别干，告诉我失败了。” ...

假设配偶是外国人，女方。 女方境外人员住宿登记表 到当地派出所领取 女方护照主页复印件 （如果有）女方护照内上次居留许可复印件 男方邀请函（移民管理局照相馆可提供） 男方户口本复印件 双方结婚证 南方身份证复印件 女方印刷出来的小照片（移民管理局照相馆可提供） 提交所有内容到当地出入境移民管理局

缓存三兄弟 缓存穿透 是什么：大量请求查询数据库不存在的数据。缓存没有，持续击打数据库 防范方法： 缓存空值 数据库查不到也往缓存放一个空标记（TTL短，2分钟，该TTL过期了才能进行再次数据库查询） 下一次同样的id来了直接被挡住 优点：有效拦截大量穿透请求 缺点： 恶意攻击造成大量不同的不存在的key，缓存堆满无效数据，浪费内存 延迟了数据一致性，新数据必须等缓存过期 布隆过滤器（推荐） 启动时把所有合法id放入布隆过滤器； 布隆过滤器不给进就真的没有； 优点： 没有高内存占用风险 没有数据一致性风险 缺点： 有极小误判率 增删要维护。数据更新时，要同步更新布隆过滤器 接口层限流和校验 API网关或Controller层做拦截 参数校验、限流降级 互斥锁重建 互斥锁主要解决缓存击穿（热点key过期），但是在缓存空对象场景下，如果有大量并发请求一个不存在的key，可以使用锁 每次访问让一个线程去查DB，其他线程等待 大厂的实践 网关层 校验参数格式，IP限流（挡掉脚本攻击） 过滤器层 布隆过滤器 缓存层 缓存击穿 是什么：某个被疯狂访问的热点key，因为TTL一到，失效的一瞬间海量并发请求同时miss，同时到DB重建同一个key 防范方法： 互斥锁 只让第1个miss的线程去查DB 其他线程等一下再读缓存 高一致性：线程傻傻等待 低一致性：先给旧数据，下一次来查就是新的 逻辑过期 key永不物理过期，把过期时间存在value里面 如果发现逻辑上过期了，异步开个线程重建 当前请求先返回旧值 互斥锁的实现 如何搭建出正确的锁？ v1：SETNX key 1 抢锁，DEL key 释放 SETNX=“不存在才设置成功”，天然互斥。但问题：抢到锁的线程崩了、DEL 没执行 → 锁永远不释放 → 死锁。 v2：给锁加过期间 崩了也能自动过期。但关键：必须用一条原子命令 SET key value NX EX 30。 陷阱：别写成 SETNX + 再 EXPIRE 两条——如果刚 SETNX 成功、还没 EXPIRE 就崩了，又变回 v1 的死锁。“抢锁"和"设过期"必须一步做完。 ...

基础知识 TCP 三次握手 客户端 - 服务器 三次握手目的：客户端的收发没问题，服务器的收发也没问题。 第一次握手：客户端发 SYN（同步请求） 客户端：我啥也不知道，我发个 SYN 消息出去，看看有没有人接收到。 如果没人回复，我再发几次（超时重传）。 这个时刻，客户端知道的事实是： 我发出去了，但不知道有没有人收到 ❌ 我能不能收消息？不知道 ❌ 对方存不存在？不知道 ❌ 第二次握手：服务器回 SYN+ACK（同步+确认） 服务器收到了客户端的 SYN。 服务器回复 SYN+ACK：“我收到你的消息了，我也发一条试试，看看你能不能收到。” 这个时刻，服务器知道的事实是： 客户端发消息是没有问题的 ✅（因为我收到了） 服务器收消息是没有问题的 ✅（因为我收到了） 服务器不知道服务器发消息有没有问题 ❌（我发出去了，但不知道对方收到没） 服务器不知道客户端收消息有没有问题 ❌（我发出去了，但不知道对方收到没） 服务器需要发送一条 SYN+ACK，等对方回复 ACK 来确认“我能发、对方能收” 当客户端收到 SYN+ACK 后，客户端可以确定以下事实： 我发消息是没有问题的 ✅（我发的 SYN 被收到了） 我收消息也是没有问题的 ✅（我收到了对方的回复） 服务器收消息是没有问题的 ✅（对方收到了我的 SYN） 服务器发消息也是没有问题的 ✅（我收到了对方的 SYN+ACK） ✅ 客户端这边已经确认全双工通信没问题了！ 但是服务器他还有顾虑（不知道自己能不能发、不知道我能不能收），我再发个 ACK 给他吧 第三次握手：客户端发 ACK（确认） 客户端收到 SYN+ACK 后，回复一个 ACK：“我收到你的 SYN+ACK 了，我这边收发都没问题，你也可以放心了。” 当服务器收到这个 ACK 后，服务器可以确定以下事实： ...

正常 JWT 请求流程 sequenceDiagram participant User as 用户 participant Frontend as 前端（浏览器/App） participant Auth as 认证服务器 participant Backend as 后端API服务器 Note over User,Backend: 1. 登录阶段 User->>Frontend: 输入用户名/密码 Frontend->>Auth: POST /login (凭证) Auth->>Auth: 验证凭证 Auth-->>Frontend: 返回 access_token + refresh_token Frontend->>Frontend: 存储token（内存/localStorage） Frontend-->>User: 登录成功 Note over User,Backend: 2. 正常请求阶段 User->>Frontend: 请求受保护资源 Frontend->>Backend: GET /api/resourceAuthorization: Bearer access_token Backend->>Backend: 验证access_token签名和过期时间 Backend-->>Frontend: 返回请求的资源 Frontend-->>User: 展示数据 Note over User,Backend: 3. Access Token过期 User->>Frontend: 继续请求 Frontend->>Backend: GET /api/resourceAuthorization: Bearer access_token(已过期) Backend-->>Frontend: 401 Unauthorized (token过期) Frontend->>Frontend: 检测到401，触发刷新逻辑 Note over Frontend,Auth: 4. 刷新Token阶段 Frontend->>Auth: POST /refreshrefresh_token Auth->>Auth: 验证refresh_token Auth-->>Frontend: 返回新的 access_token（可选的新refresh_token） Frontend->>Frontend: 更新存储的access_token Frontend->>Backend: 重试原请求（新access_token） Backend-->>Frontend: 返回请求的资源 Frontend-->>User: 展示数据 为什么不能只靠JWT refresh token 发出去后后端不保存，会变成 不可控的长期通行证 无法主动踢人下线 无法注销单点设备 无法判断 token 是否被盗用（攻击者拿到了 refresh token 可以一直刷新 access token） 无法实现会话管理 使用 refresh tokens 表后的流程图 sequenceDiagram participant User as 用户 participant Frontend as 前端 participant Auth as 认证服务器 participant DB as 数据库(refresh_tokens表) participant Backend as 后端API服务器 Note over User,DB: 1. 登录阶段（签发token + 入库） User->>Frontend: 输入用户名/密码 Frontend->>Auth: POST /login Auth->>Auth: 验证凭证 Auth->>DB: 生成唯一refresh_token_idINSERT INTO refresh_tokens(user_id, token_hash, expires_at, device_info, ip_address, revoked) DB-->>Auth: 插入成功 Auth->>Auth: 生成access_token + refresh_token(refresh_token包含id引用) Auth-->>Frontend: 返回access_token + refresh_token Frontend->>Frontend: 存储token Frontend-->>User: 登录成功 Note over User,Backend: 2. 正常请求（与之前相同） User->>Frontend: 请求资源 Frontend->>Backend: GET /api/resourceAuthorization: Bearer access_token Backend->>Backend: 验证access_token Backend-->>Frontend: 返回资源 Note over Frontend,DB: 3. Access Token过期 → 刷新 Frontend->>Backend: GET /api/resource (access_token过期) Backend-->>Frontend: 401 Unauthorized Frontend->>Auth: POST /refreshrefresh_token Note over Auth,DB: 4. 刷新验证（多步校验） Auth->>Auth: 解析refresh_token，提取token_id Auth->>DB: SELECT * FROM refresh_tokensWHERE id = token_id DB-->>Auth: 返回记录 Auth->>Auth: 校验清单： Note over Auth: ✅ token_hash是否匹配✅ 是否过期 (expires_at > now())✅ 是否被撤销 (revoked = false)✅ 用户是否仍有效✅ 设备信息是否一致（可选） alt 校验全部通过 Auth->>DB: UPDATE refresh_tokensSET last_used_at = now(), last_used_ip = current_ipWHERE id = token_id Auth->>Auth: 生成新access_token（可选：延长refresh_token有效期） Auth-->>Frontend: 返回新access_token Frontend->>Frontend: 更新access_token Frontend->>Backend: 重试原请求（新token） Backend-->>Frontend: 返回资源 else 校验失败 Auth-->>Frontend: 401/403 (刷新失败) Frontend->>Frontend: 清除所有token Frontend->>User: 跳转登录页 end Note over User,DB: 5. 主动登出 User->>Frontend: 点击登出 Frontend->>Auth: POST /logoutrefresh_token Auth->>DB: UPDATE refresh_tokensSET revoked = trueWHERE id = token_id Auth-->>Frontend: 登出成功 Frontend->>Frontend: 清除本地token Frontend-->>User: 已登出 Note over User,DB: 6. 安全场景：密码修改 User->>Frontend: 修改密码 Frontend->>Auth: POST /change-password Auth->>DB: UPDATE refresh_tokensSET revoked = trueWHERE user_id = current_user_id Note over DB: 撤销该用户所有refresh_token（强制所有设备重新登录） Auth-->>Frontend: 密码修改成功 Frontend->>Frontend: 清除本地token Frontend-->>User: 请重新登录