小程序开发，那些让人头疼的“小毛病”，您中招了吗？
说实话，咱们做小程序开发的，谁还没在教程里栽过跟头？明明一步步跟着教程走，代码敲得手都酸了，结果一运行，不是这里报个红叉叉，就是那里样式乱成一团。您是不是也遇到过这种情况？心里那个火啊，恨不得把电脑给关了！
今天，咱们不聊那些高大上的框架原理，就聊聊两个最基础、但又最折磨人的“老朋友”——ESLint和HTML/CSS。它们一个管代码规矩，一个管页面长相，偏偏是新手最容易踩坑的地方。别担心，我这就把这么多年摸爬滚打总结的“药方”分享给您，保准药到病除！
一、 ESLint：别让“代码警察”坏了您的好心情
刚开始用ESLint的时候，我简直要疯掉。每写两行代码，它就跳出来说：“这里少个分号！”“那里变量名不对！”“这行缩进应该是2个空格，你用了4个！”感觉身边站了个严厉的“代码警察”，一刻不停地挑刺。很多教程只教您怎么安装，却没告诉您怎么和它“和平共处”。
问题1：满屏红色波浪线，心态直接崩了
这是最常见的问题。您兴冲冲地打开项目，却发现编辑器里一片“血红”，错误警告几十上百个。很多朋友的第一反应是：“这玩意儿太麻烦了，关掉算了！” 坦白讲，我也这么干过。但后来发现，关掉ESLint就像开车不系安全带，短期内是舒服了，长期看隐患巨大。
解决方案：分步处理，别想着一口吃成胖子。
- 先“治病”再“预防”：对于历史遗留的、成堆的错误，别一个个手动改。在项目根目录的
.eslintrc.js文件里，暂时添加一条规则：'rules': { 'off': 0 }。这相当于给所有错误开了个“特赦令”，先让红色消失，让项目能跑起来。但这只是临时措施！ - 启用“自动纠错”：现在的编辑器（比如VSCode）和构建工具（如Webpack）基本都支持ESLint自动修复。配置好以后，保存文件时，它能自动修复大部分格式问题（像分号、缩进、引号这些）。一下子就能解决80%的烦恼。
- 定制您的规则：ESLint规则是可以商量的！比如您和团队就是习惯用双引号，那就在规则里把
quotes规则改成["error", "double"]。把它配置成符合您团队习惯的样子，它就从“敌人”变成了“帮手”。
问题2：教程代码一粘贴就报错
这事儿太常见了。网上找了一段示例代码，复制到自己项目里，ESLint立马报错。您可能会怀疑自己，是不是哪里弄错了？其实，很可能是因为教程作者的项目ESLint配置和您的不同。
解决方案：学会看错误描述，理解规则本质。
- 别光看红色波浪线，把鼠标移上去，仔细读读错误说明。ESLint会告诉您具体违反了哪条规则（Rule）。
- 拿这个规则名去ESLint官网查一下，您就知道这条规则是想干嘛（比如是为了避免使用已废弃的API，还是为了防止变量污染）。理解了意图，您就能判断：是应该修改代码，还是可以安全地禁用这条规则。
- 举个例子，有些教程会用
var声明变量，但您的ESLint配置了推荐使用let或const。这时您就知道，把var改成let就行了，而不是教程代码有问题。
二、 HTML与样式：为什么我的页面和教程里长得不一样？
说完代码规范，咱们再聊聊这“面子工程”。HTML教程看似简单，但小程序里的视图层（WXML）和Web端的HTML，虽说相似，却有不少关键区别。直接照搬Web教程，很容易掉坑里。
问题1：Div和View，傻傻分不清楚？
在传统HTML教程里，<div> 是万能的容器。但在小程序里，基本容器是 <view>。虽然它们看起来很像，但底层实现和部分属性（比如小程序特有的 hover-class）完全不同。如果您用写网页的思维写小程序，把大量HTML标签直接搬过来，那肯定是行不通的。
解决方案：建立小程序专属的“组件思维”。
- 把
<view>当作您的新<div>，把<text>当作必须用来包裹文本的标签（小程序里，直接写在<view>里的文本可能无法被正确选中或设置样式）。 - 多去翻看小程序的官方组件文档。这是最权威的“教程”，里面详细列出了每个组件（如
button,image,scroll-view）的属性和用法。这比任何第三方教程都靠谱。
问题2：CSS样式“失灵”了？
“我这个Flex布局在Chrome里明明好好的，怎么到小程序模拟器上就乱了？” 这种问题我听过太多遍了。原因主要有两个：一是小程序有自己的一套样式渲染引擎，和浏览器有细微差异；二是小程序的样式是局部作用域的，这既是优点也是坑。
解决方案：拥抱局部样式，善用调试工具。
- 理解样式隔离：在小程序中，每个页面的样式（.wxss文件）默认只作用于当前页面。这避免了全局污染，但也意味着您不能直接在页面A里写样式去影响页面B的组件。如果真有需要复用的样式，请把它定义成公共样式，或者使用小程序的“外部样式”特性。
- 使用模拟器的“审查元素”：小程序开发工具自带的调试器，和Chrome DevTools非常像。当样式不对劲时，别光靠猜，用这个工具去选中元素，实时查看它最终计算出的样式是啥，优先级如何。这是定位样式问题最快的方法！
- 注意兼容性：一些较新的CSS属性（如部分CSS Grid特性）在小程序里可能支持不全。在用到炫酷的新特性前，最好先在官方文档或真机上测试一下。
三、 把教程变成您自己的“开发流水线”
知道了这些具体问题的解法，咱们再往上拔高一层。怎么才能避免总是被这些问题缠上，让开发过程更顺畅呢？
我的经验是，不要被动地跟着教程学，要主动建立自己的开发习惯和检查清单。
- 项目初始化时：别急着写代码。先花10分钟，和团队统一好ESLint规则（用哪个预设？要关闭或修改哪些规则？），并配置好编辑器的自动格式化。这一步的投入，会在未来节省您无数个小时。
- 学习新教程时：带着“对比”的眼光去看。看到一段代码，先想：“这是Web的HTML还是小程序的WXML？”“这个CSS属性在小程序里能用吗？” 这样能帮您快速过滤掉不适用信息，抓住核心逻辑。
- 遇到报错时：形成条件反射。第一步，仔细读错误信息；第二步，用错误关键词去搜索（小程序的问题，优先搜微信开放社区）；第三步，如果还不行，就简化问题，写一个最简短的代码片段来复现它。90%的问题，都能通过这三步解决。
写在最后：从“跟着做”到“知道为什么这么做”
咱们今天聊的这些ESLint和HTML/CSS的坑，其实都是成长路上的“磨刀石”。每一次解决它们，您对小程序的开发规范、运行原理的理解就会更深一层。
教程的作用是带您入门，给您一个可行的路径。但真正的熟练，来自于在踩坑和填坑中积累的经验。当您再看到ESLint报错能淡定分析，当您能预判某个CSS属性在小程序里的表现时，您就从一个教程的跟随者，变成了一个真正的开发者。
如果您也想摆脱教程依赖，少走弯路，建立起自己高效稳定的小程序开发流程，不妨就从今天提到的这两点开始实践。先搞定ESLint，让它为您服务；再吃透小程序的视图组件，把基础打牢。相信我，当这些基础问题不再是您的障碍时，您就能把更多精力放在实现酷炫的业务逻辑和用户体验上了！
开发之路，我们一起进步！
