背景：一个看似简单，实则处处是坑的需求

上个月接到一个任务：在 uni-app 项目中实现一个图片裁剪插件，支持缩放、旋转和拖拽。我第一反应是“这不简单吗？网上模板一大堆，让 AI 写一个不就完了？”于是，我打开常用的 AI 代码助手，把需求描述得清清楚楚：用 uni-app 写一个图片裁剪组件，支持手势缩放、旋转、拖拽，兼容 H5 和微信小程序。

AI 秒回一个完整的 vue 组件，代码结构清晰，注释到位。我心里一阵窃喜：这效率，以后谁还自己写？结果一跑，直接翻车。H5 端页面卡死，小程序端裁剪框歪了，旋转后图片飞出边界。更离谱的是，AI 生成的代码里，touch 事件直接用了 @touchmove.prevent，在微信小程序里压根不生效。

于是，我开始了“AI 写一版，我改一版”的循环。前后改了三个大版本，踩了无数坑，才算勉强跑通。这篇文章就来聊聊——AI 写 uni-app 插件到底靠不靠谱，以及我们该怎么用好它。

问题分析：AI 编程的“三大盲区”

在改代码的过程中，我逐渐摸清了 AI 的弱点。它擅长的是“拼凑”，而不是“适配”。

1. 平台差异被忽略
   uni-app 最大的特点就是跨平台。AI 生成的代码往往默认“一套逻辑走天下”。比如，在 H5 端，touch 事件处理非常自由，可以用 e.touches[0] 直接取坐标；但在微信小程序里，touches 对象的 clientX 和 pageX 在不同组件层级下表现不同。AI 生成的裁剪组件，在小程序里拖拽时，坐标计算完全错位，因为没考虑到 uni.createSelectorQuery() 的异步特性。

2. 边界情况全靠猜
   AI 会写“理想状态”的代码，但不会考虑用户的实际操作。比如，它生成的旋转逻辑是：每次旋转 90°，然后更新 transform。但用户如果连续快速旋转，或者先旋转再缩放，图片的 transform-origin 就会乱。AI 没有处理这种“状态叠加”的场景，导致图片在多次操作后直接飞出去。

3. 性能优化完全缺失
   uni-app 的 H5 端和原生小程序端，性能模型完全不同。AI 生成的代码在 H5 端用 v-bind:style 动态绑定 transform，每次手指滑动都触发一次重渲染。这在 H5 上勉强能跑，但在小程序里，由于 setData 的异步机制和渲染层与逻辑层的通信开销，直接导致页面卡死。AI 不会主动考虑用 requestAnimationFrame 节流，也不会用 computed 缓存计算结果。

第一版：推倒重来，从“事件模型”开始改

第一版 AI 代码的核心逻辑是：在 touchstart 时记录初始位置，touchmove 时更新 transform: translate(X, Y) scale(S) rotate(R)。看起来没问题，但小程序里一跑，拖拽时有延迟，而且缩放后图片边界不对。

问题定位：AI 用了 @touchmove="onTouchMove"，但在 onTouchMove 里直接计算并赋值给 this.style。在小程序里，touchmove 事件触发频率极高（每秒几十次），每次都要执行 setData 更新样式，性能瓶颈就在这里。

解决方案：改用 uni.createSelectorQuery() 获取组件边界，然后用 requestAnimationFrame 节流。具体来说：

javascript
// 节流函数，控制更新频率
let ticking = false;
function onTouchMove(e) {
if (!ticking) {
requestAnimationFrame(() => {
updateTransform(e.touches[0]);
ticking = false;
});
ticking = true;
}
}

同时，把 transform 的计算结果缓存到 computed 属性里，只在手势结束时才一次性写入 data。这样，setData 的调用次数从每秒几十次降到每秒一次。

踩坑记录：requestAnimationFrame 在微信小程序里是支持的，但要注意，它返回的是一个 number 类型的 ID，不能用 cancelAnimationFrame 直接取消（因为小程序的实现有差异）。我的做法是：用一个 flag 变量控制，而不是依赖 cancelAnimationFrame。

第二版：旋转与缩放的“叠加噩梦”

第二版改完，拖拽和缩放基本 ok，但旋转加入后，问题又来了。用户先旋转 90°，再缩放 2x，图片位置会跳变。原因是 AI 的旋转逻辑是：每次旋转后，重新计算 transform: translate(x, y) scale(s) rotate(r)，但 x 和 y 是基于初始坐标的，旋转后图片的视觉中心变了，translate 的偏移量却没更新。

问题定位：旋转改变了图片的坐标系，但 translate 的偏移量还是基于原始坐标系计算的。比如，图片中心在 (100, 100)，旋转 90° 后，中心点还在 (100, 100)，但图片的视觉边界变了。AI 没有考虑“旋转后中心点偏移”这个细节。

解决方案：改用“矩阵变换”的思路，而不是直接操作 translate、scale、rotate。因为 transform: matrix() 可以统一处理所有变换，而且能保持坐标系的连续性。

javascript
// 使用矩阵变换，把所有操作叠加到一个 matrix 上
let currentMatrix = [1, 0, 0, 1, 0, 0]; // [a, b, c, d, tx, ty]

function applyRotation(angle) {
const rad = angle Math.PI / 180;
const cos = Math.cos(rad);
const sin = Math.sin(rad);
// 矩阵乘法：旋转矩阵 当前矩阵
currentMatrix = [
cos currentMatrix[0] + sin currentMatrix[2],
cos currentMatrix[1] + sin currentMatrix[3],
-sin currentMatrix[0] + cos currentMatrix[2],
-sin currentMatrix[1] + cos currentMatrix[3],
currentMatrix[4],
currentMatrix[5]
];
updateStyle();
}

踩坑记录：矩阵变换虽然精准，但在 uni-app 里，transform: matrix() 的兼容性要特别注意。微信小程序支持 matrix，但 H5 端的某些旧版浏览器可能不支持。我的做法是：在 onReady 里用 uni.getSystemInfoSync() 判断平台，如果是 H5 且版本低，就回退到 translate + scale + rotate 的分步写法。

第三版：裁剪框的“边界锁定”与“用户体验”

前两版跑通后，第三版主要解决裁剪框的边界锁定问题。AI 生成的代码里，用户可以把图片拖到裁剪框外面，然后裁剪出空白区域。这显然不行。

问题定位：AI 只计算了图片的 transform 值，但没有计算图片在裁剪框内的有效显示区域。它不会自动判断“图片边缘是否超出裁剪框边界”，更不会做“边界回弹”。

解决方案：在每次手势结束时，计算图片的四个角在裁剪框坐标系中的坐标，然后做边界约束。

javascript
function clampBounds() {
// 获取裁剪框的尺寸（假设已知 width, height）
const cropRect = { x: 0, y: 0, w: cropWidth, h: cropHeight };
// 获取图片当前变换后的四个角坐标（通过矩阵计算）
const corners = getImageCorners(currentMatrix, imageWidth, imageHeight);
// 计算需要偏移的量，保证所有角都在裁剪框内
let dx = 0, dy = 0;
for (const corner of corners) {
if (corner.x cropRect.x + cropRect.w) dx = Math.min(dx, cropRect.x + cropRect.w - corner.x);
if (corner.y cropRect.y + cropRect.h) dy = Math.min(dy, cropRect.y + cropRect.h - corner.y);
}
// 更新矩阵的平移部分
currentMatrix[4] += dx;
currentMatrix[5] += dy;
updateStyle();
}

用户体验优化：边界锁定后，用户如果拖动到边缘，会感觉“卡死了”。我加了弹性效果：当图片边缘超出边界时，用 transition: all 0.2s ease-out 让图片“弹回”边界内。这样用户操作时，手感更自然。

踩坑记录：弹性效果在 H5 端用 CSS transition 就行，但在小程序里，transition 对 transform 的支持有限（特别是微信小程序的旧版基础库）。我的做法是：用 uni.createAnimation() 创建动画实例，手动控制回弹的缓动效果。

注意事项：AI 编程的“靠谱度”边界总结

通过这次三版迭代，我总结了几条 AI 编程的“靠谱度”边界，供大家参考：

1. AI 擅长的：快速生成“骨架代码”，比如组件的基本结构、事件绑定、样式模板。这些工作重复性高，AI 效率极高。
2. AI 不擅长的：处理平台差异、边界情况、性能优化、用户体验细节。这些需要开发者对 uni-app 的底层机制有深入理解。
3. 建议做法：让 AI 写 70% 的代码（基础功能 + 模板），自己写 30% 的“硬核”部分（事件处理、状态管理、性能优化）。不要期望 AI 能输出一个生产级的插件。
4. 测试策略：AI 生成的代码，一定要在“最小环境”里测试，比如单独创建一个空白 uni-app 项目，只引入这个组件，测试 H5 和微信小程序两个端。等基础功能 ok，再集成到实际项目中。

总结：AI 是“实习生”，不是“主力”

这次经历让我从一个“AI 万能论者”变成了“AI 实用主义者”。AI 能帮我们省下写模板的时间，但真正决定代码质量的，还是我们自己对 uni-app 的理解深度。比如，你是否知道 uni-app 的 touch 事件在 H5 和小程序里的坐标系差异？你是否了解 requestAnimationFrame 在跨平台下的兼容性？这些知识，AI 不会主动告诉你，只能靠你自己去踩坑、去总结。

如果你也想用 AI 写 uni-app 插件，我的建议是：先让 AI 写一个“玩具版”，然后基于这个“玩具版”去迭代。不要指望一次成型。每次迭代，你都会发现自己对问题的理解更深一层。这，可能才是 AI 编程真正有价值的地方——它逼着我们思考那些原本会被忽略的细节。

如有更好的解决方法，欢迎大家评论和指正。

• 目前存在的问题

  1. IOS平台 通用启动界面的应用名称，会使用回退语言，没有实现国际化配置，可参考iOS平台自定义storyboard启动界面；
  2. 还有目前没有涉及到的国际化，如：uniCloud和Android、IOS的strings 等。

• 项目根目录下 locale 文件夹

  ├── locale  
  │   ├── en.json  
  │   ├── index.js  
  │   ├── // 如果有其他语言，如日语，则添加 ja.json  
  │   ├── uni-app.en.json  
  │   ├── // 如果有其他语言，如日语，则添加 uni-app.ja.json  
  │   ├── uni-app.zh-Hans.json  
  │   ├── uni-app.zh-Hant.json  
  │   ├── zh-Hans.json  
  │   └── zh-Hant.json  

  这里做下简单说明：

  1. uni-app.*.json 这些文件，决定了手机系统桌面应用名称、默认启动图显示名称和系统默认 tabbar 定义的国际化；
  2. uni-app.*.json 使用跟官方文档一致 如：%app.name%，%privacyDescription.NSBluetoothAlwaysUsageDescription%

  ---

  1. index.js

     import en from './en.json'  
     import zhHans from './zh-Hans.json'  
     import zhHant from './zh-Hant.json'  
     // import ja from './ja.json'  
     export default {  
         en,  
         'zh-Hans': zhHans,  
         'zh-Hant': zhHant,  
         // 如果有其他语言，如日语，则添加 ja  
     }  

  2. en.json

     {  
         "tabbar.index": "Home",  
         "tabbar.list": "List",  
         "tabbar.me": "Me",  
     
         // ... 其他字段  
     }  

  3. zh-Hans.json

     {  
         "tabbar.index": "首页",  
         "tabbar.list": "列表",  
         "tabbar.me": "我的",  
     
         // ... 其他字段  
     }  

  4. zh-Hant.json

     {  
         "tabbar.index": "首頁",  
         "tabbar.list": "清單",  
         "tabbar.me": "我的",  
     
         // ... 其他字段  
     }  

  配置应用名称和IOS平台配置隐私权限描述国际化，还有一种方式官方提供的 manifest.json国际化配置【本文章末尾】

  注意： 我试过在uni-app.en.json中把隐私权限描述写到下面ios内打包,没有效果

    // 这里是错误说明,不要这样写，正确写法是下面的 uni-app.en.json 示例  
    {  
        "common": {  
            "app.name": "app name",  
            "app.description": "app description",  
        },  
        "ios": {  
            "privacyDescription":{  
                "NSBluetoothAlwaysUsageDescription": "Requires access to your Bluetooth to function properly",  
                "NSBluetoothPeripheralUsageDescription": "Requires access to your Bluetooth to function properly"  
            }  
        },  
        "android": {}  
    }  

  ---

  1. uni-app.en.json

     {  
         "common": {  
             "app.name": "app name",  
             "app.description": "app description",  
     
             "privacyDescription.NSBluetoothAlwaysUsageDescription": "Requires access to your Bluetooth to function properly",  
             "privacyDescription.NSBluetoothPeripheralUsageDescription": "Requires access to your Bluetooth to function properly"  
         },  
         "ios": {},  
         "android": {}  
     }  

  2. uni-app.zh-Hans.json

     {  
         "common": {  
             "app.name": "应用名称",  
             "app.description": "应用描述",  
     
             "privacyDescription.NSBluetoothAlwaysUsageDescription": "需要访问您的蓝牙以正常工作",  
             "privacyDescription.NSBluetoothPeripheralUsageDescription": "需要访问您的蓝牙以正常工作"  
         },  
         "ios": {},  
         "android": {}  
     }  

  3. uni-app.zh-Hant.json

     {  
         "common": {  
             "app.name": "應用名稱",  
             "app.description": "應用描述",  
     
             "privacyDescription.NSBluetoothAlwaysUsageDescription": "需要訪問您的藍牙以正常工作",  
             "privacyDescription.NSBluetoothPeripheralUsageDescription": "需要訪問您的藍牙以正常工作"  
         },  
         "ios": {},  
         "android": {}  
     }  

• manifest.json

1. 配置 manifest.json 的默认语言 在 manifest.json 中设置 locale 为 "auto"，这是跟随系统语言的关键。

   {  
       "name": "%app.name%",  
       "appid": "__your_appid__",  
       "locale": "auto" // 设置为 auto，跟随系统 os 的语言  
       "fallbackLocale" : "en" // 默认回退语言 这个根据自己需求设置  
       // ... 其他配置  
   }  

2. 配置 android 和 ios 原生平台支持的语言列表 （关键步骤） 这一步在标准基座下由 dcloud 预先完成，但你的应用必须自行配置，否则打包后系统无法识别你的应用支持哪些语言，通常会回退到默认语言 （如英文）。【这里不提供详细示例，可以直接看官方文档中的示例】

   {  
       "app-plus" : {  
           "locales": {  
               "en": {}, // 英文  
               "zh": {}, // 中文  （特别注意）  
               "zh-Hans": {}, // 简体中文  
               "zh-Hant": {}, // 繁体中文  
               // 如果有其他语言，如日语，则添加 "ja": {}  
           }  
       }  
   }  

   关于"zh": {} 这个配置说明：

   1. 如果这个"zh": {}不配置，当系统语言是【简体中文】，应用名称和隐私权限描述会回退到【默认语言】，而不是使用【简体中文】-搞不懂为什么
   2. 虽然官方文档语言代码中提到locales下的键名（key）可以取值示例，没有zh-Hans和zh-Hant两个键名，但是实际测试中，其可以正常工作，其他键名会回退到【默认语言】，而不是当前【系统语言】

现在有3个安卓原生sdk，分别是
1-称重的，
2-ai识别物品的，
3-人脸识别的，

要封装成插件，让我们在uniapp开发的app中调用。
能接的v：xxxx1024xxxx1024

我花了149 元人民币 ，买了你们AI 一个月的 订阅，每天就一个问题 ，额度就没有了，我用codex 和claude code 都能解决很多问题，你们这个额度是不是在骗人呀，也没有客服， 你们是一帮不懂经营的人再搞这个吗。

用VSCode插件+Claude实现uni-app截图转代码的实战记录

上周设计师又扔过来一沓截图，我对着“个人中心”页面的设计稿，手指在键盘上悬了三秒——又要从头写一遍套的布局吗？作为跨端项目里的“截图搬运工”，我太清楚这种重复劳动有多磨人了：打开截图，对照着像素调间距，一行一行敲template，一个普通列表页半小时起步。更扎心的是，这种工作做完就忘，下次换个颜色改个文案，又得重来。

某天下午，我盯着桌面上几十张截图发呆，突然想到：Claude的多模态能力已经能识别图片内容，为什么不能让它直接吐出可运行的uni-app代码？但每次手动拖图进Claude、复制代码、粘贴到项目里，中间至少有七八步操作。于是，一个“截图→右键→生成Vue文件”的念头冒了出来，我花了两个晚上搓了个VSCode插件，把整个流程塞进了一个右键菜单里。

为什么截图转代码是个“看起来简单，做起来翻车”的事

动手前，我列了几个绕不过去的坎。不是所有截图AI都能看懂，也不是所有生成的代码都能直接跑起来。

第一个坑：uni-app的语法不是标准Vue。 AI如果没见过、这些组件，大概率会甩出一堆，然后你手动改成，再调整移动端适配。更烦人的是，uni.xxx API 和 Vue Router 完全是两套东西，AI 生成的页面跳转逻辑基本得重写。

第二个坑：截图里的样式信息是“伪3D”。 AI只能靠视觉猜测间距和颜色，但实际项目里我们用flex布局、rpx单位、scoped样式。它生成的代码经常是margin: 20px硬撑，换个屏幕就崩了。最离谱的一次，Claude给我生成了font-size: 4rpx，我盯着那个小到肉眼看不见的字，哭笑不得。

第三个坑：代码只有壳，没有魂。 登录页截图上显示着输入框和按钮，但AI不会帮你写表单校验、不会处理提交后的跳转、不会绑定v-model。它只能画个皮，里面的逻辑还得你自己填。

我的目标很明确：不是要一个“一键生成完整App”的噱头，而是让开发者从“对着截图敲布局”变成“对着截图改逻辑”。把最无聊的部分——写template、调间距——交给AI，剩下的业务逻辑自己掌控。

插件怎么串起来的：右键→AI→生成文件

核心思路超级简单：在VSCode里选中一张截图，右键点击，Claude API 生成代码，然后自动创建.vue文件并打开。全程不用切窗口，不用复制粘贴。

技术选型上的取舍

• 插件框架：VSCode Extension API + TypeScript，注册一个右键菜单命令，只在图片文件上显示。
• AI模型：Claude 3.5 Sonnet。我试过GPT-4o和Gemini，Claude在视觉理解和代码格式规范上最平衡，而且system prompt能很好地约束输出结构。
• 图片处理：直接传base64给API，省去文件上传的麻烦。

实现流程里的三个关键节点

1. 注册命令
   在package.json里定义extension.uniImageToCode命令，绑定右键菜单，通过vscode.window.activeTextEditor获取选中文件路径。

2. Prompt设计——这是最烧脑的部分
   我写了一个详细的system prompt，核心要求包括：

   • 必须用uni-app组件（view、scroll-view、uni-list等），禁止
   • 样式用rpx单位，字体至少28rpx，布局优先flex
   • 输出完整的++三段式
   • 输入框用uni-easyinput并给出v-model绑定
   • 列表用uni-list和uni-list-item，并定义基础的data数组

特别加了一句反例提示：“不要使用，应该用”，因为Claude经常把中划线写成驼峰。

3. 处理AI返回的不完整代码
   第一次测试时，Claude只返回了template，没有script。后来我在prompt里加了“请确保输出完整的单文件组件代码，不要省略任何部分”，并在后端做了校验：如果返回内容不包含export default，就重新请求一次。另外，API的max_tokens设成4000，因为uni-app组件代码通常较长，设小了会被截断。

核心代码片段（简化版）

typescript
// 读取图片转base64
const imageBuffer = fs.readFileSync(imagePath);
const base64Image = imageBuffer.toString('base64');

// 调用Claude API
const response = await axios.post('https://api.anthropic.com/v1/messages', {
model: 'claude-3-5-sonnet-20241022',
max_tokens: 4000,
messages: [{
role: 'user',
content: [
{ type: 'text', text: systemPrompt },
{ type: 'image', source: { type: 'base64', media_type: mimeType, data: base64Image } }
]
}]
});

// 提取代码块并创建文件
const code = response.data.content[0].text;
const template = code.match(/[\s\S]*?/)[0];
const script = code.match(//)[0];
const style = code.match(//)[0];
const fullCode = ${template}\n${script}\n${style};

// 写入新文件（如 login.png → login.vue）
vscode.workspace.fs.writeFile(newUri, Buffer.from(fullCode));
vscode.window.showTextDocument(newUri);

API key没有硬编码，通过VSCode配置项让用户自行设置，也支持从环境变量读取。

实战体验：哪些场景真香，哪些翻了车

插件写完后，我拿真实项目里的截图测了一遍，结果有惊喜也有槽点。

真香场景：结构清晰的静态页面，比如设置页、个人中心、商品列表。生成的代码基本可以直接跑，样式还原度大概70%——间距、颜色、字体大小都挺准，布局结构从几十行flex缩减到微调几处。最省时间的是表单页，输入框、按钮、校验框架都给你搭好了，改改字段名就能用。

翻车现场：

• 复杂交互页面：带tab切换、下拉刷新、上拉加载的，Claude生成的代码只是样子像，逻辑基本不可用。比如tab切换它用了v-if硬切换，没有缓存也没有动画，需要自己重写。
• 第三方组件库：截图里用了uView或ThorUI的组件，Claude不认识，直接生成普通的view替代，失去了组件化的优势。这点目前无解，除非我在prompt里把组件库的API全写进去。
• 特殊字体和图标：截图里的图标，Claude会用硬写Unicode字符，而不是用字体图标组件，导致样式和交互都丢失。

我的使用建议：插件最适合生成静态页面或简单的表单/列表页。对于复杂交互的页面，先让它生成骨架，然后对照截图手动补充事件和API调用。另外，生成后一定要检查样式里的rpx值，Claude偶尔会抽风给出不合理的数值（比如字体4rpx，明显是错的）。

效果对比与下一步计划

从手动截图+写代码的30分钟，缩短到生成+微调的5分钟，这是最直观的收益。虽然不完美，但方向对了——把开发者从“像素级还原”中解放出来，专注于业务逻辑和交互设计。

接下来几个想加的功能：

• 支持选择生成风格：比如生成uView组件版本还是原生uni-app版本，通过prompt里的组件库约束实现。
• 增量更新：如果已经有一个.vue文件，只更新template部分，保留原有的script逻辑。这需要解析AST，比较复杂，但很实用。
• 本地模型支持：考虑接入Ollama运行小模型，避免每次都调用云端API，既省钱又保护隐私。不过本地模型的视觉能力目前还差一些，可能只适合简单的页面。

代码已经放在GitHub上了（链接就不放了，搜“uni-app截图转代码”应该能找到）。如果你也在做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的“智能判断”。

2. 自定义组件传值：小程序对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']，否则在微信开发者工具里会一直报“未注册事件”。

3. 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太长直接请求失败的情况。

4. 页面生命周期混用：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操作。

5. 样式兼容：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永远填不上。

Google Play 审核到底是机器还是人工？——DCloud 开发者实战分析

背景：Google Play 审核，开发者心中的“黑箱”

作为一名长期使用 uni-app 开发跨平台应用的开发者，我深知 Google Play 审核的复杂性。很多同行在 DCloud 社区里抱怨，明明在本地测试一切正常，提交到 Google Play 却被拒绝，而且拒绝理由往往模糊不清，比如“违反广告政策”“隐私政策不完整”或“权限使用不当”。更让人困惑的是，有时修改一个小问题后秒过，有时却要等上几天，甚至反复提交多次才能通过。于是，一个核心问题浮出水面：Google Play 的审核到底是由机器自动完成的，还是有人工介入？这个问题直接关系到我们如何优化应用、避免踩坑。

实际上，Google Play 的审核机制并非单一模式，而是机器与人工结合的混合系统。机器负责初步筛选和自动化检查，人工则处理复杂、模糊或高风险的案例。对于使用 uni-app 框架的开发者来说，理解这一机制至关重要，因为我们的应用通常依赖 WebView、原生插件和第三方 SDK，这些都可能触发机器审核的“雷区”。本文将从实战角度，分析 Google Play 审核的底层逻辑，并给出针对 uni-app 开发者的具体解决方案。

问题分析：机器审核的“硬伤”与人工审核的“盲区”

机器审核：速度与规则的博弈
机器审核是 Google Play 的第一道防线，它通过自动化脚本和算法扫描应用的代码、元数据、权限声明等。机器擅长处理确定性规则，比如检查是否包含恶意代码、是否使用了违规的 API（如非必要的后台位置权限），或者是否在描述中夸大了功能。例如，如果你的 uni-app 应用在 manifest.json 中声明了 android.permission.ACCESS_BACKGROUND_LOCATION，但实际功能不涉及后台定位，机器会直接标记为“权限滥用”，并拒绝提交。

机器审核的优点是速度快，通常在几分钟到几小时内完成。但它的缺点也很明显：缺乏上下文理解。比如，你的应用使用了一个第三方推送 SDK，该 SDK 在运行时动态申请了 READ_PHONE_STATE 权限，机器会认为这是应用主动申请的，从而触发“隐私政策不完整”的警告。实际上，这个权限只是 SDK 用于设备标识，但机器不会去深究 SDK 的文档。

人工审核：深度与效率的妥协
当机器无法做出明确判断时，或者应用被用户举报、被系统标记为高风险（如涉及金融、医疗或儿童内容），审核就会转交给人工团队。人工审核员会手动安装应用、测试功能、阅读隐私政策，甚至模拟用户行为。例如，如果你的 uni-app 应用包含一个 WebView 内嵌的 H5 页面，该页面加载了第三方广告，人工审核员可能会检查广告内容是否合规，或者是否在用户不知情的情况下收集了数据。

人工审核的优点是能处理复杂场景，比如判断某段代码是“功能需要”还是“恶意收集”。但它的缺点是效率低，且主观性强。同一款应用，不同审核员可能给出不同结论，这就是为什么有时修改一个标点符号就能通过，而有时调整整个功能架构却依然被拒。

对 uni-app 开发者的特殊影响
uni-app 应用本质上是混合架构，前端代码运行在 WebView 中，原生功能通过插件桥接。这种架构容易让机器审核产生误判。例如，机器可能将 WebView 的 JavaScript 代码视为动态加载内容，从而怀疑应用存在“代码混淆”或“动态下载”行为。而人工审核员如果不懂跨平台技术，可能会错误地认为 WebView 加载的 H5 页面是“第三方内容”，要求提供额外的合规证明。因此，理解审核机制后，我们需要针对性地调整开发策略。

解决方案：如何让 uni-app 应用顺利通过审核

1. 优化权限声明，避免“机器误判”
   机器审核最敏感的就是权限。在 uni-app 中，权限声明集中在 manifest.json 的 distribute 节点下。很多开发者为了方便，直接复制网上的权限列表，结果包含了大量不必要的权限。例如，android.permission.CAMERA 和 android.permission.RECORD_AUDIO 只应在实际用到时声明。

步骤：

• 检查 manifest.json 中的 标签，只保留应用核心功能所需的权限。
• 对于第三方插件（如推送、支付），逐一查看其官方文档，确认它们实际需要的权限，并在代码中通过 plus.android.requestPermissions 动态申请，而非在清单中静态声明。
• 如果必须使用敏感权限（如位置、相机），确保在隐私政策中明确说明用途，并在代码中实现“权限申请弹窗”，解释为什么需要该权限。

代码示例（在 uni-app 中动态申请权限）：
javascript
// 在页面加载时，检查并申请相机权限
plus.android.requestPermissions(
['android.permission.CAMERA'],
function(e) {
if (e.deniedAlways.length > 0) {
// 权限被永久拒绝，引导用户去设置
uni.showModal({
title: '提示',
content: '需要相机权限才能扫码，请前往设置开启',
success: (res) => {
if (res.confirm) {
plus.runtime.openURL('app-settings://');
}
}
});
} else if (e.deniedPresent.length > 0) {
// 权限被临时拒绝，可再次请求
// do nothing
} else {
// 权限已授予，执行扫码逻辑
}
}
);

2. 谨慎使用 WebView，避免“动态加载”嫌疑
   机器审核对动态加载内容非常警惕，因为它可能被用于绕过审核（如加载违规页面）。在 uni-app 中， 组件是常见的功能载体，但如果你将其指向一个外部 URL，机器可能会标记为“不可控内容”。

步骤：

• 尽量使用本地 HTML 文件，而非远程 URL。例如，将 H5 页面打包到应用资源中，通过 src="/static/page.html" 加载。
• 如果必须加载远程页面，确保该域名在隐私政策中列出，并且页面内容不包含违规信息（如赌博、色情）。同时，在 manifest.json 中配置 标签，明确声明你访问的域名。
• 避免在 WebView 中执行复杂的 JavaScript 代码，例如动态创建 iframe 或加载外部脚本。这些行为容易被机器视为“恶意注入”。

3. 完善隐私政策，应对人工审核
   人工审核员会仔细阅读你的隐私政策，并对照应用的实际行为。很多 uni-app 开发者直接在隐私政策中粘贴模板，然后忘记更新，导致与实际功能脱节。例如，你使用了友盟统计，但隐私政策中只字不提，人工审核员会直接拒绝。

步骤：

• 在隐私政策中逐条列出所有收集数据的 SDK，包括名称、用途、收集的数据类型（如设备 ID、IP 地址）。对于 uni-app 常用的插件（如 uni-push、uni-AD），也要单独说明。
• 在应用首次启动时，实现一个“隐私政策弹窗”，用户必须点击“同意”后才能进入主界面。这个弹窗需要包含“阅读并同意”按钮，并且链接到完整的隐私政策页面。
• 如果应用涉及用户生成内容（UGC），在隐私政策中明确声明你的审查机制，例如“用户发布的内容会经过人工审核”。

代码示例（uni-app 中实现隐私政策弹窗）：
vue

        欢迎使用本应用，请阅读并同意隐私政策  
        查看隐私政策  
        同意  

export default {
data() {
return { privacyAgreed: false };
},
methods: {
agreePrivacy() {
// 将同意状态存储到本地，下次启动不再弹窗
uni.setStorageSync('privacyAgreed', true);
this.privacyAgreed = true;
}
},
onLoad() {
this.privacyAgreed = uni.getStorageSync('privacyAgreed') || false;
}
}

4. 避免代码混淆与动态下载
   机器审核会扫描 APK 中的代码结构，如果发现大量混淆或动态加载的 Dex 文件，会认为应用存在“隐形行为”。uni-app 应用本身使用 V8 引擎执行 JavaScript，这部分代码相对透明，但如果你引入了原生插件，这些插件可能经过混淆。

步骤：

• 对于自定义原生插件，尽量使用 ProGuard 的默认规则，避免过度混淆。特别是插件暴露给 JS 层的接口，不要混淆，否则会导致运行时错误。
• 不要在运行时从远程服务器下载代码或资源（如更新插件）。如果需要热更新，使用 uni-app 的官方热更新机制（通过 App 资源更新），而非自行实现动态加载。
• 如果必须使用动态加载（如加载 A/B 测试代码），确保相关逻辑在隐私政策中说明，并限制在非核心功能上。

5. 提前测试，模拟机器审核
   在提交前，使用 Google Play Console 的“预发布报告”功能，它能模拟机器审核的扫描结果。另外，也可以借助第三方工具，如 AppBrain 或 DCloud 的打包检测工具，检查权限和 API 使用情况。

步骤：

• 在 Google Play Console 中，进入“发布”->“测试”，上传 APK 或 AAB 后，查看“预发布报告”。它会列出潜在的违规项，如权限滥用、SSL 错误等。
• 使用 Android Studio 的 Profile 工具，查看应用运行时实际申请的权限，与 manifest.json 中的声明对比，删除冗余项。
• 在 DCloud 社区中，搜索“Google Play 审核”关键词，查看其他开发者的经验贴，特别是针对同一插件（如 uni-push）的审核案例。

注意事项：常见“雷区”与应对策略

• 不要忽视 SDK 版本更新：Google Play 每年都会更新审核规则，例如要求所有应用必须适配 Android 13 的“通知权限”或“照片选择器”。如果你的 uni-app 应用使用的旧版 SDK（如旧版 uni-push）没有适配，机器会直接拒绝。建议定期检查 DCloud 插件市场，更新到最新版本。
• 避免在描述中夸大功能：机器审核会读取应用标题、描述和关键词。如果你写“免费无限存储”，但实际只有 1GB 空间，会被标记为“虚假描述”。人工审核员也会对比描述和实际功能。
• 注意多语言版本：如果你的应用支持多语言，确保每个语言版本的隐私政策和权限声明都同步更新。否则，人工审核员测试中文版时发现权限描述与英文版不一致，同样会被拒绝。
• 处理用户举报：一旦应用被用户举报（如收集隐私数据），审核会立即转交人工处理。此时，你需要在 Google Play Console 中提供详细的技术说明，解释数据收集的必要性，并附上隐私政策链接。

总结：知己知彼，百战不殆

回到最初的问题：Google Play 审核到底是机器还是人工？答案是两者皆有，且分工明确。机器负责快速过滤硬性违规，人工则处理需要判断力的复杂情况。对于 uni-app 开发者来说，理解这一机制的核心意义在于：将应用设计成“机器友好”且“人工可解释”。

具体来说，你需要做到：

• 精简权限声明，让机器一眼看出你的应用是“无辜”的。
• 完善隐私政策，让人工审核员觉得你的应用是“透明”的。
• 避免动态加载和过度混淆，让代码路径清晰可见。
• 提前使用工具测试，把问题消灭在提交前。

最后，记住 Google Play 审核不是一次性的，而是一个持续的过程。随着应用更新，审核规则也可能变化。作为 DCloud 社区的一员，我建议你定期关注官方文档和社区动态，及时调整开发策略。毕竟，让应用顺利上架，才是我们共同的目标。

App 已经成功上架，为什么苹果开发者账号还是被封了？这是我后来才明白的事

很多开发者都会觉得：

只要 App 能成功上架，说明账号已经安全了。

我以前也是这样认为的。

毕竟审核都通过了，应用也已经在 App Store 正常下载，按理来说后续应该只是更新版本、维护功能，不会再有什么大问题。

直到后来，一个已经稳定运营了一段时间的开发者账号突然被终止，我才开始重新研究苹果的审核逻辑。

事实证明，审核通过和账号安全，并不是一回事。

当时到底发生了什么？

那个账号并不是第一次提交应用。

前面的版本都顺利通过审核，产品也一直正常运营。

后来只是一次普通的版本更新，原本以为几天就能审核完成，结果审核时间越来越长，随后收到了苹果关于账号的处理通知。

刚开始我一直觉得是不是这次代码写错了。

后来复盘整个账号，才发现问题并没有这么简单。

苹果真正评估的是整个开发者账号

很多开发者只关注这一次提交的 IPA。

实际上，苹果更关注的是整个开发者账号的表现。

例如：

• 提交过哪些应用
• 每个应用之间是否存在高度相似
• 是否经常因为同类问题被拒
• 是否存在重复业务
• 应用更新是否长期保持稳定
• 是否存在误导性的元数据

这些信息都会不断累积。

也就是说，账号是有”历史记录”的。

并不会因为一次审核通过，就把之前所有情况全部清零。

我后来发现，真正危险的是”长期积累”

有一次审核通过，并不能说明以后一直都会通过。

真正容易出现问题的，往往是下面这些情况。

相似应用越来越多

刚开始只有一个工具类 App。

后来增加第二个。

第三个。

第四个。

如果这些应用只是换了名称、Logo 或主题，而底层实现高度一致，那么随着数量增加，被关注的概率也会增加。

很多开发者觉得：

“以前都是这么做的，也通过了。”

但实际上，审核标准、审核模型以及账号历史都会不断变化。

每次都只是为了过审

还有一种情况，就是每次修改都只是为了让审核通过。

哪里被拒改哪里。

功能没有真正优化，业务没有真正完善。

长时间下来，账号会留下大量审核记录。

虽然每一次都可能成功，但整体表现未必理想。

更新越来越频繁

为了赶进度，有时候一天提交一次。

甚至一天修改两三次。

这种方式虽然能够提高试错速度，但也容易让账号产生大量审核记录。

如果再叠加其他因素，风险自然会上升。

后来我们的做法变了

经历过那次之后，我们已经不会再等审核发现问题。

每次准备提交之前，都会提前检查：

• 功能是否真正独立
• 页面是否存在大量重复
• 是否新增了容易触发审核的问题
• 元数据是否准确描述功能
• 新版本是否与历史版本保持合理演进

虽然准备时间更长了一点，但后面的审核明显稳定了很多。

最后想说

很多开发者把苹果审核理解成一次考试。

其实更像是一份长期档案。

每一次提交、每一次修改、每一次被拒，都会成为账号历史的一部分。

所以，真正需要维护的，不只是某一个 App，而是整个开发者账号的长期信誉。

只有把账号当成长期资产去运营，而不是只想着快速通过一次审核，后续更新才会越来越顺利。

更多文章看我主页

为 uni-app (Vue 3) 提供类似 vue-router 风格的路由管理系统（uni_modules 版本）。

仅支持 Vue 3 — 基于 Vue 3 Composition API，不支持 Vue 2 项目。

特性

• vue-router 风格 API - push / replace / relaunch / back
• 路由守卫 - beforeEach / beforeResolve / afterEach / beforeEnter，支持 guardRoute 冷启动补执行
• 页面间通信 - useUniEventChannel 内置通信管理器，粘性缓存确保时序安全
• 声明式组件 - RouterLink / TabBar / TabBarItem，easycom 自动注册
• 页面参数传递 - params 传递复杂数据，back() 后自动保留
• 查询参数增强 - queryInt() / queryNumber() / queryBool()
• 错误处理 - RouterError / NavigationFailure / UniApiError，instanceof 精准判断

安装

将 mxuni-router 目录复制到项目的 uni_modules 目录下即可，无需 npm 安装。

快速开始

// main.ts  
import { createSSRApp } from 'vue'  
import { createRouter } from './uni_modules/mxuni-router/js_sdk/index.js'  
import App from './App.vue'  

const router = createRouter({  
    routes: [  
        { path: 'pages/index/index', name: 'home', meta: { title: '首页' } },  
        { path: 'pages/about/about', name: 'about', meta: { requireAuth: true } }  
    ],  
    interceptUniApi: true  
})  

export function createApp() {  
    const app = createSSRApp(App)  
    app.use(router)  
    return { app }  
}

组件在 uni_modules 中自动注册，直接使用即可：

<RouterLink to="/pages/about/about">关于</RouterLink>  

<TabBar selected-color="#007aff">  
    <TabBarItem to="/pages/index/index" text="首页" />  
    <TabBarItem to="/pages/about/about" text="关于" :badge="5" />  
</TabBar>

文档

📖 https://mengxi-studio.github.io/uni-router/v1/

License

MIT

自己实现的插件只能点击跳转很不美观

@meng-xi/uni-router

为 uni-app (Vue 3) 提供类似 vue-router 风格的路由管理系统（uni_modules 版本）。

⚠️ 仅支持 Vue 3 — 本库基于 Vue 3 Composition API（inject / ref / defineProps / defineEmits）和 app.provide 等 Vue 3 专属 API，不支持 uni-app Vue 2 项目。

特性

• vue-router 风格 API - push / replace / relaunch / back，零学习成本
• 路由守卫 - beforeEach / beforeResolve / afterEach / beforeEnter，支持 next(location, { mode }) 指定重定向方式
• 命名路由 & 路由元信息 - 通过 name 导航，meta 携带自定义数据
• TypeScript 类型提示 - 路由名称和路径自动补全与类型检查
• uni API 拦截 - 可选拦截原生导航 API，统一守卫流程（interceptUniApi）
• 页面间通信 - useUniEventChannel 启用后所有导航方式均支持 eventChannel 双向通信，目标页通过 usePageChannel() 获取通道，基于 uni.$emit 全局事件总线，粘性缓存确保时序安全
• 声明式导航 - RouterLink 组件，基于 uni navigator 封装，支持导航参数、动画、页面通信
• 页面参数传递 - params 传递复杂数据，不暴露在 URL，支持 persistent 持久化
• 查询参数增强 - queryInt() / queryNumber() / queryBool() 便捷解析
• 导航动画 - push / replace / back 支持动画参数，仅 App 端生效
• 路由状态同步 - syncRoute() 处理浏览器后退、物理返回键等场景
• 错误处理 - 完整的 RouterError / NavigationFailure 体系，onError 全局捕获
• 组合式 API - useRouter() / useRoute() / usePageChannel() 响应式访问路由与通信通道

安装

uni_modules（推荐）

将 mxuni-router 目录复制到项目的 uni_modules 目录下即可，无需 npm 安装。

npm

pnpm add @meng-xi/uni-router

npm 方式需将导入路径改为 @meng-xi/uni-router。

快速开始

1. 创建路由器

// main.ts  
import { createSSRApp } from 'vue'  
import { createRouter } from './uni_modules/mxuni-router/js_sdk/index.js'  
import App from './App.vue'  

const router = createRouter({  
    routes: [  
        { path: 'pages/index/index', name: 'home', meta: { title: '首页' } },  
        { path: 'pages/about/about', name: 'about', meta: { title: '关于', requireAuth: true } }  
    ],  
    strict: true,  
    interceptUniApi: true, // 拦截 uni 原生导航 API，确保守卫生效  
    useUniEventChannel: true // 启用内置通信管理器，所有导航方式支持页面间双向通信  
})  

export function createApp() {  
    const app = createSSRApp(App)  
    app.use(router)  
    return { app }  
}

2. 路由导航

import { useRouter, useRoute } from './uni_modules/mxuni-router/js_sdk/index.js'  

const router = useRouter()  
const route = useRoute() // 返回响应式引用，路由变化时自动更新  

// 路径导航  
await router.push({ path: '/pages/about/about', query: { id: '1' } })  

// 命名导航  
await router.push({ name: 'about' })  

// 页面参数传递（params 不暴露在 URL，支持复杂数据）  
await router.push({ path: '/pages/detail/detail', params: { info: { name: 'Tom' } } })  

// 返回（执行完整守卫链）  
await router.back()

3. 页面间通信

启用 useUniEventChannel 后，所有导航方式均返回 eventChannel，目标页通过 usePageChannel() 获取通道：

// ===== 发起页 =====  
const result = await router.push({ path: '/pages/detail/detail' })  
result.eventChannel?.on('ready', data => console.log('目标页已就绪:', data))  
result.eventChannel?.emit('data', { msg: '发给目标页的数据' })  

// ===== 目标页（detail.vue）=====  
import { usePageChannel } from './uni_modules/mxuni-router/js_sdk/index.js'  

const channel = usePageChannel() // 无 __nav_id 时返回 noopChannel，无需判空  
channel.on('data', data => console.log('收到发起页数据:', data))  
channel.emit('ready', { status: 'ok' }) // 粘性缓存：发起页尚未注册 on 也能收到

4. 路由守卫

router.beforeEach((to, from, next) => {  
    if (to.meta.requireAuth && !isLoggedIn()) {  
        // 使用 replace 模式重定向，避免登录页之后残留受保护页面的历史  
        next({ name: 'login', query: { redirect: to.fullPath } }, { mode: 'replace' })  
    } else {  
        next()  
    }  
})

5. 自动生成路由配置（推荐）

配合 @meng-xi/vite-plugin 的 generateRouter 插件，可从 pages.json 自动生成路由配置和类型声明：

pnpm add @meng-xi/vite-plugin -D

// vite.config.ts  
import { defineConfig } from 'vite'  
import uni from '@dcloudio/vite-plugin-uni'  
import { generateRouter } from '@meng-xi/vite-plugin'  

export default defineConfig({  
    plugins: [  
        uni(),  
        generateRouter({  
            pagesJsonPath: 'src/pages.json',  
            outputPath: 'src/router.config.ts',  
            dts: true,  
            metaMapping: {  
                navigationBarTitleText: 'title',  
                requireAuth: 'requireAuth'  
            }  
        })  
    ]  
})

然后在 main.ts 中导入生成的路由配置：

import { createRouter } from './uni_modules/mxuni-router/js_sdk/index.js'  
import routes from './router.config'  

const router = createRouter({ routes })

文档

完整的 API 参考、配置项说明、RouterLink 组件属性、类型定义等请查阅官方网站：

📖 https://mengxi-studio.github.io/uni-router/

License

MIT

1.AI无法撤回到历史聊天记录

2.你们的AI只要一个项目，打开多个vue，会一起更改

3.你说你们有历史会话，但是他麻痹的会压缩，AI根本读不完

4.AI改了代码，不明确修改了哪里，我tm找了半天找到按钮，点击 接受 更改，哎你猜怎么着，无法接受，点了和没点一样，依然显示xxx行更改，

5.总结，你们tm要做AI给我做好了啊，基础的东西都没有，就en改啊