Web编程

凌晨两点，我盯着浏览器里那个空白页面，F12控制台报错红得像急诊室的心电图。这已经是今晚第七次刷新了——不是页面崩溃，而是我写的JavaScript函数压根没被触发。隔壁房间传来室友均匀的鼾声，而我正和一段addEventListener代码较劲。这种时刻，你会特别清楚地意识到：Web编程不是写代码，是跟浏览器谈判。

浏览器是个固执的谈判对象。你给它HTML，它按自己的规则解析；你给它CSS，它可能因为一个分号漏掉就推翻整个布局；你给它JavaScript，它偏要等你把所有资源加载完才肯执行。我见过太多新手栽在“为什么我的代码没反应”上——不是逻辑错，是脚本放在<head>里，DOM还没生成就急着绑定事件。这就像你对着空房间喊“开门”，门把手都还没装上。

但真正让我头皮发麻的，是CSS那个“层叠”的脾气。上周我调一个导航栏的阴影，明明写了box-shadow: 0 2px 4px rgba(0,0,0,0.1)，页面死活不显示。查了半天，发现是父容器设了overflow: hidden，把阴影活生生截断了。这种问题，文档里不会写，教程里不会教，只有被坑过才记得住。Web开发里最贵的不是框架授权费，是这种“哦——原来如此”的顿悟时刻所耗费的深夜。

说到框架，我承认React和Vue确实让状态管理变得像搭积木。但有时候我觉得它们把简单的事搞复杂了——一个简单的点击换文字功能，原生JS十行搞定，用框架得装依赖、建组件、管props。可当你需要维护一个几百个交互组件的后台系统时，原生代码会变成蜘蛛网，而框架至少给你一张地图。这不是技术之争，是工具匹配度的问题。

有个现象特别有意思：Web编程可能是唯一一个“会跑就行”和“跑得稳”差距极大的领域。你可以用document.write()写个页面，也能用WebAssembly做视频剪辑。但绝大多数现实项目卡在中间地带——数据要实时更新，界面要响应式，还要兼容那个2016年的老iPad。这时候你才明白，HTTP状态码200不代表成功，页面能打开不代表用户不骂娘。

我认识一个做电商后台的朋友，他每天的工作就是跟“异步请求竞态”搏斗。用户快速点击“提交订单”三次，后端收到三个请求，数据库里出现三条记录。这种问题在本地测试永远复现不了，只有生产环境的高延迟网络才会触发。他说自己像在修一座永远漏水的船，补好一个洞，水压又会从另一个缝隙渗进来。但他说这话时眼睛发亮——因为每次修好一个洞，他都能感觉到自己对这个系统的理解又深了一层。

说到底，Web编程的魅力就在于这种“半失控感”。你写的每一行代码，最终都要交给一个你无法完全掌控的浏览器去解释执行。Chrome和Safari对同一个CSS属性的渲染差异，比北京和上海的方言差距还大。但正是这种不确定性，逼着你不断测试、验证、调整。当你在IE11的怪癖模式下找到一个兼容方案时，那种成就感比拿到offer还实在。

凌晨四点，我终于发现那个函数没触发的原因——我把事件绑定写在了window.onload外面，而页面里有个图片加载超时，导致整个load事件永远没触发。删掉那行多余的包裹代码，刷新，页面活了。屏幕的光映在脸上，我听见自己笑了一声。窗外有鸟叫，新的一天开始了。浏览器还开着，控制台干净得像刚擦过的玻璃。