为什么技术探索与实践？——一个手写代码老派程序员的深夜碎碎念
上周五晚上十一点半，我还在工位上对着终端发呆。窗外北京国贸的霓虹灯早就亮透了，办公室里就剩我和隔壁组那个总穿拖鞋的运维小哥。他一边啃煎饼果子一边问我：“你这又在折腾啥呢？”
我说：“搞个 K8s 的自定义控制器，想让前端部署更丝滑点。”
他翻了个白眼：“兄弟，都 AI 时代了，你还在手撸 YAML？Copilot 三秒给你生成一套。”
我笑了笑没说话，心里却有点复杂。
入职这家公司刚满两个月，团队氛围其实不错——大家都挺卷，但卷得有分寸。产品需求排得跟春运火车票一样紧，上周还因为一个“微前端加载慢 200ms”的问题被 PM 追着问是不是能优化到“用户感觉不到”。我心想：大哥，那是网络延迟，不是代码慢啊！
不过说真的，要不是这次被逼着做前端性能治理，我可能这辈子都不会深入去碰 JavaScript 的模块联邦（Module Federation）和动态 chunk 加载策略。毕竟我可是云原生出身，K8s Operator 写得比吃饭还顺手，JS 在我印象里还是 var 和回调地狱的时代。
但现实就是这么打脸。技术探索从来不是兴趣驱动，而是问题倒逼。
从一道面试题开始的“中年危机”
事情得从一个月前说起。那天 HR 突然拉我去支援校招面试，让我出几道“有深度但别太难”的题。我随手翻了翻自己的旧笔记，想起之前自己跳槽时被问过的一道题：
“如何在不刷新页面的情况下，动态加载并执行远程 JavaScript 模块？”
当时我答的是 JSONP + eval，结果面试官一脸“你这人是不是还在用 IE6”的表情。后来我才知道，现在早就有 Webpack Module Federation、Vite 的 dynamic import、甚至浏览器原生的 ES Modules 动态加载了。
那一刻我突然意识到：我的简历上写着“全栈能力”，但实际上对前端工程化的理解还停留在 jQuery 时代。而现在的业务，偏偏要求前后端协同部署、灰度发布、按需加载——尤其是我们做的 SaaS 平台，客户定制化需求多到爆炸，每个租户都要加载不同的功能模块。
如果我还抱着“后端万能论”不放，迟早会被现实按在地上摩擦。
实战：让 JS 模块像 Pod 一样按需调度
既然躲不过，那就干。
我们的目标很明确：主应用只加载核心框架，其余功能模块（比如报表、审批流、BI 看板）按需从 CDN 动态拉取并挂载到页面上。听起来像微前端？没错，但我不想引入 qiankun 那种重型方案——太重，学习曲线陡，而且和我们现有的 K8s 发布流程耦合度低。
于是我决定用最“朴素”的方式：原生 ES Modules + 动态 import + 缓存策略。
// utils/dynamicLoader.js
const moduleCache = new Map();
export async function loadRemoteModule(url) {
if (moduleCache.has(url)) {
return moduleCache.get(url);
}
try {
// 动态加载远程 JS 模块（必须是 ESM 格式）
const module = await import(url);
moduleCache.set(url, module);
console.log(`✅ 模块 ${url} 加载成功`);
return module;
} catch (err) {
console.error(`❌ 加载模块失败: ${url}`, err);
throw new Error(`Failed to load module from ${url}`);
}
}
关键点来了：这个 URL 必须指向一个合法的 ESM 模块，也就是文件头要有 export，且服务器响应头必须包含 Content-Type: application/javascript 和 Access-Control-Allow-Origin（跨域问题永远的痛）。
第一次测试时，我把模块打包成 IIFE 格式扔到 OSS 上，结果浏览器报错：
Uncaught TypeError: Failed to resolve module specifier "https://cdn.example.com/feature-a.js"
我当时真的想砸电脑——明明本地 file:// 能跑，线上就不行。后来才想起来：ES Modules 只能在 HTTP(S) 环境下加载，且必须是 CORS 允许的资源。
于是我又跑去求运维小哥帮忙配 Nginx：
location ~* \.js$ {
add_header Access-Control-Allow-Origin *;
add_header Content-Type application/javascript;
}
他边改边吐槽：“你们前端能不能统一用个 CDN 平台？每次都要我手动加 header，我快成前端保姆了。”
和 K8s 的奇妙联动
既然都做到这一步了，为什么不把前端模块也纳入云原生体系？
我们现在的部署流程是：Git 提交 → CI 构建 Docker 镜像 → Helm 部署到 K8s。但前端静态资源是单独上传到 OSS 的，版本管理和回滚特别麻烦。
灵光一闪：能不能把前端模块打包成 ConfigMap，由 K8s 控制器动态注入到 Ingress 或 Service Mesh 中？
说干就干。我写了一个简单的 Operator，监听 FrontendModule 自定义资源：
apiVersion: frontend.example.com/v1
kind: FrontendModule
metadata:
name: report-module
spec:
version: v1.2.3
url: https://cdn.example.com/report-v1.2.3.js
enabled: true
tenants: ["tenant-a", "tenant-b"]
Operator 会根据这个 CRD 生成对应的 Nginx 配置片段，或者更新 Istio 的 VirtualService，实现基于租户的模块路由。这样一来，PM 想给某个客户开新功能？直接改个 YAML 就行，不用动代码、不用重新构建镜像。
上线那天，我特意选在周五晚上——反正周末没人用系统，炸了也有人背锅（不是）。
结果居然一次过！浏览器控制台清清爽爽地输出：
✅ 模块 https://cdn.example.com/report-v1.2.3.js 加载成功
那一刻，我盯着屏幕傻笑了五分钟。不是因为技术多牛，而是终于把“代码人生”从被动响应变成了主动设计。
面试题挑战？不，是生存挑战
回头看看，当初那道面试题，其实根本不是考你会不会写 import()，而是看你有没有在复杂约束下解决问题的能力。
现在的技术栈越来越像乐高：K8s 是底座，Service Mesh 是管道，前端模块是可插拔的积木。如果你只会拼一种颜色，迟早会被淘汰。
我翻了翻自己的简历，以前写的都是“精通 K8s、熟悉 Docker、掌握 Helm”。现在我打算加上一句：
“擅长通过技术探索将业务痛点转化为可落地的工程方案，哪怕这意味着要从零学 JavaScript。”
听起来有点中二，但这就是事实。
手写代码 vs AI 辅助：我的平衡之道
我知道很多人会说：“你这何必呢？Copilot 三句话就能生成 dynamic import 封装。”
但我想说：AI 是扳手，不是工程师。
上周我让 Copilot 帮我写个缓存逻辑，它给我返回了一个用 localStorage 存 module 的方案。乍看没问题，但没考虑模块更新后的缓存失效——这在线上就是 P0 事故。
而我自己手写的时候，会本能地想到：
- 缓存要不要带版本号？
- 失败要不要降级？
- 跨域怎么处理？
- 浏览器兼容性如何？
这些细节，AI 不会替你思考。它只能放大你的认知边界，而不是替代它。
所以我现在的做法是：核心逻辑手写，重复样板用 AI 生成。比如 YAML 配置、CLI 命令、日志格式——这些我让 Copilot 干。但涉及业务规则、错误处理、安全边界的地方，我必须亲手敲。
深夜写代码的效率高，不是因为安静，而是因为没人打扰你思考。这时候，每一行代码都是你和问题的直接对话。
最后：技术探索的意义，不在简历，在呼吸
前几天团建，leader 问大家：“你们觉得技术人的核心竞争力是什么？”
有人说算法，有人说架构，有人说沟通。
我说：“是持续把未知变成已知的能力。”
去年双11，我们因为没做前端懒加载，首屏加载 8 秒，被老板在全员会上点名。今年，同样的流量，首屏 1.2 秒——因为我们敢把 JS 模块拆出去，敢用 K8s 管前端资源，敢在 deadline 前推翻重来。
这些经历不会写进简历的“项目经验”里，但它们刻进了我的代码风格里。
所以，回到最初的问题：为什么要做技术探索与实践？
不是为了应付面试题挑战，不是为了让简历多一行“熟悉 XXX”，而是因为——
当你面对一个线上告警、一个愤怒的 PM、一个无法复现的 Bug 时，你希望自己手里有不止一把锤子。
而探索的过程，就是不断往工具箱里添新家伙的过程。
凌晨一点，我关掉终端，看了眼窗外。国贸的灯还亮着，不知道哪个角落还有和我一样的“手写代码保守派”，正对着一段报错信息死磕。
没关系，明天太阳照常升起，Bug 也会继续出现。
但至少今晚，我又多懂了一点 JavaScript。
评论 0