试了一圈AI编程助手，发现写uni-app时还是得自己动手调这几个坑

去年接了个uni-app外包，想着用AI编程助手冲一下效率，结果差点翻车翻到沟里。

Copilot、Cursor、通义灵码挨个试了一遍，它们写页面模板确实快——一个列表页、一个表单，几秒就给你整出来。但一碰到uni-app的跨端细节，AI就像个刚毕业的实习生：代码看起来能跑，一部署到小程序就崩给你看。下面这5个坑，是我亲手填过的，AI永远填不上。

1. 条件编译：AI把它当普通if-else用

uni-app的#ifdef和#ifndef是跨端生存的关键，但AI写代码时，经常把平台逻辑混在一起，甚至直接写个if (process.env.PLATFORM === 'h5')——这玩意儿在微信小程序里根本跑不动。

真实翻车现场：我需要在小程序端调wx.getUserProfile，H5端用uni.getUserInfo。AI甩给我一段代码：

javascript
uni.getUserProfile({
desc: '用于完善资料',
success: (res) => console.log(res.userInfo)
});

在H5端直接报错——getUserProfile不存在。我手动拆成条件编译：

javascript
// #ifdef MP-WEIXIN
uni.getUserProfile({
desc: '用于完善资料',
success: (res) => this.userInfo = res.userInfo
});
// #endif

// #ifdef H5
uni.getUserInfo({
provider: 'weixin',
success: (infoRes) => this.userInfo = infoRes.userInfo
});
// #endif

血泪教训：AI经常把#ifndef H5写成#ifndef MP-WEIXIN，逻辑反了。每次写完条件编译，我都手动跑一遍所有目标端的模拟器，别信AI的“智能判断”。

1. 自定义组件传值：小程序对props类型有洁癖

uni-app支持Vue的props，但在小程序端，props不能传函数类型。AI不懂这个，生成了这样的代码：

vue
// 子组件
点击
props: {
onSuccess: Function
}

微信开发者工具直接报警告：“props不能接受Function类型”。我改成$emit事件机制才搞定：

vue
// 父组件

// 子组件
点击
export default {
emits: ['success'],
methods: {
emitSuccess() {
this.$emit('success', { data: '...' });
}
}
}

坑点：AI生成的组件代码里，emits选项经常漏掉，事件传递直接失效。手动补上emits: ['success']，否则在微信开发者工具里会一直报“未注册事件”。

1. uni.request封装：AI给的拦截器有毒

AI推荐用axios封装请求，但uni-app在小程序端不支持axios（没有XMLHttpRequest）。AI给的代码是：

javascript
import axios from 'axios';
const instance = axios.create({ baseURL: '...' });

H5端能跑，小程序端直接报错。我换成uni.request手动封装：

javascript
// request.js
const baseURL = 'https://api.example.com';

function request(options) {
const token = uni.getStorageSync('token');
const header = {
'Content-Type': 'application/json',
...(token ? { 'Authorization': Bearer ${token} } : {})
};

return new Promise((resolve, reject) => {
uni.request({
url: baseURL options.url,
method: options.method || 'GET',
data: options.data,
header: { ...header, ...options.header },
success: (res) => {
if (res.statusCode === 200) resolve(res.data);
else if (res.statusCode === 401) {
uni.navigateTo({ url: '/pages/login/login' });
reject(new Error('Unauthorized'));
} else reject(new Error('Request failed'));
},
fail: (err) => {
uni.showToast({ title: '网络异常', icon: 'none' });
reject(err);
}
});
});
}

export default request;

隐藏坑：AI生成的代码经常忘记处理401，或者把uni.navigateTo写成uni.redirectTo，导致登录后无法返回。另外，uni.request的header在小程序端有长度限制（大概4KB），AI不会告诉你——我遇到过token太长直接请求失败的情况。

1. 页面生命周期混用：onLoad和mounted分不清

uni-app的onLoad和Vue的mounted执行顺序不同，AI经常把需要页面参数的处理逻辑塞进mounted里。

真实翻车：从列表页跳转详情页，需要获取options.id。AI写了：

javascript
mounted() {
const id = this.$route.query.id; // H5端能用，小程序端this.$route不存在
}

小程序端直接报错。我统一改为onLoad：

javascript
export default {
onLoad(options) {
this.id = options.id;
this.fetchDetail();
},
mounted() {
// 只做DOM初始化，比如图表渲染
// 不依赖this.id
}
}

坑点：AI经常在onLoad和mounted里都调用fetchDetail，导致接口请求两次。我习惯只保留onLoad里的请求，mounted只做DOM操作。

1. 样式兼容：rpx和px混用成灾难

uni-app推荐用rpx做响应式单位，但AI生成的样式里px、rpx、vw混用，在不同屏幕尺寸下布局直接崩。

我的手动规则：

• 字体大小：font-size: 28rpx（用rpx）
• 固定宽高（按钮、图标）：width: 100rpx（用rpx）
• 边框、阴影：border: 1px solid #ccc（用px）
• 百分比布局：width: 100%或flex

AI翻车案例：一个卡片组件，AI写了padding: 20px，在iPhone 12上正常，iPhone SE上右边距过大。改成padding: 30rpx后适配了所有屏幕。

坑点：AI有时生成calc(100vw - 40rpx)这种混合表达式，小程序端编译报错。统一用rpx，需要百分比宽度时用width: 100%配合padding。

最后说点实在的

别把AI当救世主。它写模板、列表页、基础逻辑确实快，但uni-app的跨端细节、条件编译、原生API调用、生命周期管理，这些坑它一个都填不上。

我的工作流：

1. 只把AI当草稿生成器：用它写页面结构和基础逻辑，然后手动检查跨端兼容性。
2. 建自己的代码片段库：把条件编译、请求封装、组件传值这些高频模式整理成模板，比让AI每次重新生成靠谱得多。
3. 多在小程序端测试：AI生成的代码在H5端往往能跑，小程序端才是真正的“照妖镜”——我至少有一半的bug是在微信开发者工具里发现的。

最后，别迷信AI的“智能”。至少在uni-app这个领域，人类的“手动调”仍然是不可替代的——因为那些坑，AI永远填不上。