技术类

动手！部署你的第一个 K8s 应用 一、目标说明 上一篇文章把 Docker 和 K8s 的概念地图铺开了。这篇文章要做的是：真正动手，在本地 K8s 集群上部署一个完整的应用。 读完这篇文章，读者能： 验证本地 K8s 环境是否可用 写出一个完整的 Deployment YAML（并理解每一行在说什么） 写出 Service 让 Pod 可以稳定访问 用 ConfigMap 和 Secret 把配置从镜像里拆出来 用 kubectl apply 把整套东西一键部署 通过 kubectl port-forward 在浏览器里访问应用 二、前置条件 前置条件 要求 验证命令 Docker Desktop 已安装 4.x+ docker version Kubernetes 已开启 Docker Desktop Settings → Kubernetes → Enable Kubernetes kubectl cluster-info kubectl 已安装 Docker Desktop 自带 kubectl version --client 上一篇的概念理解 知道 Image / Container / Pod / Deployment / Service 是什么 脑子过一遍层级：Image → Container → Pod → Deployment 如果 kubectl cluster-info 输出类似以下内容，说明环境就绪： ...

Docker 与 K8s：从困惑到搞懂 一、目标说明 这篇文章要解决一个问题：一个从来没碰过容器的后端开发，怎么搞懂 Docker 和 K8s 那一堆名词？ 读完这篇文章，读者能搞清楚以下事情： Docker 的 Image（镜像）和 Container（容器）到底是什么关系 为什么有了 Docker 还不够，还要搞一个 K8s 出来 K8s 的 Master / Worker Node 上各自跑了哪些组件，它们怎么配合 Pod、Deployment、Service、ConfigMap、Secret、Namespace 这些概念分别解决什么问题 一个 kubectl apply 命令背后，K8s 集群里发生了什么 ⚠️ 新手提示：这篇文章不会让你动手敲任何命令。目的是在脑子里建一张"K8s 全景地图"。有了这张地图，后面写 YAML、敲 kubectl 的时候才知道每一行是在操作什么东西。 二、前置条件 读者需要具备以下基础（都很基本）： 前置知识 要求程度 验证方式 Linux 基本命令 会用 cd 、 ls 、 cat 、 ps 打开终端敲一下看看 进程概念 知道一个程序运行起来就是一个进程 打开任务管理器看一眼 IP + 端口 知道 127.0.0.1:8080 是什么意思 用过浏览器访问 localhost 即可 YAML 格式 见过 YAML，知道缩进表示层级 写过 Spring Boot 的 application.yml 就算 如果以上都 OK，往下看。 ...

Long类型ID前端精度丢失：从IEEE 754根因到Jackson全局序列化方案 🤔 一、问题切入：一个"找不着"的订单 某天业务反馈：用户在订单详情页点进去一片空白，后台日志里看到查的是 ID 1857353925587607500，但数据库里根本没有这条记录。翻看上游接口的原始响应体，后端明明返回的是 1857353925587607552。 差了多少？不多，就差了 52：...552 变成了 ...500。但这 52 的差距足以让一条订单从数据库里彻底"消失"。 写个最简单的演示： // 后端：Java Long 值 long orderId = 1857353925587607552L; System.out.println(orderId); // 输出: 1857353925587607552 ✓ 后端没问题。再看前端： // 前端：直接解析后端返回的 JSON const json = '{"orderId": 1857353925587607552}'; const obj = JSON.parse(json); console.log(obj.orderId); // 输出: 1857353925587607500 ✗ 同一个数字，跨了一道 HTTP 就被"阉割"了最后两位精度。这不是哪家框架的 bug，也不是谁写错了代码——根因在 JavaScript Number 的底层存储格式。 flowchart TD classDef data fill:#052e16,stroke:#16a34a,stroke-width:1.5px,color:#bbf7d0,font-weight:bold; classDef reject fill:#450a0a,stroke:#dc2626,stroke-width:1.5px,color:#fecaca,font-weight:bold; classDef process fill:#1e1e24,stroke:#6b7280,stroke-width:1.5px,color:#e5e7eb; JAVA[Java Long\n1857353925587607552] JSON[JSON 数字\n1857353925587607552] PARSE[JavaScript JSON.parse] NUM[JS Number\n1857353925587607500] QUERY[用错误ID查数据库] MISS[查不到数据] JAVA -->|Jackson序列化| JSON JSON -->|HTTP响应| PARSE PARSE -->|IEEE 754精度丢失| NUM NUM --> QUERY QUERY --> MISS class JAVA,JSON data; class NUM,MISS reject; class PARSE,QUERY process; 这个问题的触发条件很具体：后端 Long 值超过 9007199254740991（即 2^53 ~ 1，约 16 位十进制数）时，前端 JSON.parse() 解析出的数字就会丢失精度。雪花算法生成的 ID 通常 17 ~ 19 位，正好踩在坑里。 ...