.redirects.gollum
... ...
@@ -23,3 +23,4 @@ dowload.md: 下载接口认证失败.md
23 23
UAT/hotFix版本.md: UAT/HOTFIX或UAT版本.md
24 24
upgrad.md: "./admin.md"
25 25
版本发布/前后端版本更新信息.md: 版本发布/./91426.md
26
+web-front-standard.md: "./admin91426.md"
admin91426.md
... ...
@@ -0,0 +1,311 @@
1
+<!--[[_TOC_]]-->
2
+# IIDP前端开发规范
3
+
4
+[[http://192.168.175.198:10003/iidpminio/home/logo.png]]
5
+
6
+# 前言
7
+
8
+希望IIDP开发者通过阅读本手册，能够充分利用IIDP平台进行开发，避免常见的错误和陷阱，写出高质量的代码，提高开发效率。让我们一起码出高效、码出质量的软件系统。
9
+
10
+# 开发规范
11
+
12
+## 命名规范
13
+
14
+### 项目文件命名
15
+
16
+1、项目文件名
17
+
18
+【推荐】命名方法：kebab-case 字母小写短横线连接
19
+
20
+正例：whclould-smart-port / my-project-name
21
+
22
+反例：My-Project
23
+
24
+2、目录名
25
+
26
+【推荐】有复数结构时，要采用复数命名法
27
+
28
+正例：assets、components、directives、mixins、utils、views
29
+
30
+### 组件命名
31
+
32
+1.【强制】 组件命名规范，组件名称必须唯一
33
+
34
+说明：在IIDP平台中，确保组件名称的唯一性，便于识别和管理。 tech-作为名称前缀，具体的组件名作为后缀名称。
35
+
36
+正例：tech-button / tech-dialog / tech-upload / tech-custom-multi-input 使用时type：button
37
+
38
+反例：custom-multi-input 没有tech-作为名称前缀，会导致使用时type：custom-multi-input不显示这个组件
39
+
40
+
41
+2、单文件组件名
42
+
43
+【推荐】单文件组件名应该始终是单词大写开头 (PascalCase)，大驼峰式命名法。
44
+
45
+正例：CustomComponent.vue
46
+
47
+反例：my-Component.vue
48
+
49
+3、基础组件名
50
+
51
+【推荐】基础组件在一个页面内可使用多次，在不同页面内也可复用，是高可复用组件。应该全部以一个特定的前缀开头 —— Base
52
+
53
+正例：BaseButton.vue/ BaseInput.vue
54
+
55
+反例：myButton.vue
56
+
57
+4、业务组件
58
+
59
+【推荐】掺杂了复杂业务的组件（拥有自身 data、prop 的相关处理）即业务组件应该以 Custom 前缀命名。
60
+
61
+正例：CustomCard.vue
62
+
63
+反例：myCard.vue
64
+
65
+5、组件名中单词顺序
66
+
67
+【推荐】组件名应该以高级别的 (通常是一般化描述的) 单词开头，以描述性的修饰词结尾。组件名尽量以完整单词命名，单词尽量语义化，方便阅读。
68
+
69
+正例：SearchContent.vue
70
+
71
+反例：ContSech.vue
72
+
73
+### 代码参数命名
74
+1、【推荐】在声明 prop 的时候，其命名应该始终使用 camelCase(小驼峰式命名)，而在模板和 JSX 中应该始终使用 kebab-case(短横线连接式)。我们单纯的遵循每个语言的约定，在 JavaScript 中更自然的是 camelCase。而在 HTML 中则是 kebab-case
75
+
76
+正例：camelCase
77
+
78
+反例：camel-Case
79
+
80
+2、router属性
81
+
82
+【推荐】Vue Router Path 命名采用 kebab-case (短横线连接式)格式。或者PascalCase(大驼峰命名)，推荐使用kebab-case 短横线。 用 Snake(下划线连接式)（如：/user_info）或 camelCase(小驼峰命名)（如：/userInfo)的单词会被当成一个单词，搜索引擎无法区分语义
83
+
84
+3、模板中组件
85
+
86
+对于绝大多数项目来说，在单文件组件和字符串模板中组件名应该总是 PascalCase(大驼峰命名) 的，但是在 DOM 模板中总是 kebab-case (短横线连接式)的。
87
+
88
+4、全局变量，全局方法名称使用应用名称+功能名称
89
+
90
+ 正例:
91
+```js
92
+ const IOT_THEME_OPTIONS = ['blue', 'red', 'green']
93
+
94
+ function iotGetSearchParams(params){
95
+ console.log(params)
96
+ }
97
+```
98
+
99
+反例： const MY_TE = ['blue', 'red', 'green']
100
+
101
+5、变量
102
+
103
+命名规范：类型 + 对象描述或属性的方式
104
+
105
+正例：camelCase
106
+
107
+6、常量
108
+
109
+命名规范：使用大写字母和下划线来组合命名，下划线用以分割单词，力求语义表达完整清楚
110
+
111
+正例：const MAX_COUNT = 10 //全部大写下划线分割
112
+
113
+反例： const MC = 10
114
+
115
+7、方法
116
+
117
+命名规范：统一使用动词或者动词 + 名词形式
118
+
119
+正例：jumpPage、loginIn、openDialog、getListApi、refresh
120
+
121
+反例：pageGet
122
+
123
+8、事件方法
124
+
125
+命名规范：handle + 名称（可选）+ 动词
126
+
127
+正例：
128
+```js
129
+<el-pagination
130
+ @size-change="handleSizeChange"
131
+ @current-change="handleCurrentChange"
132
+ :current-page.sync="currentPage"
133
+ :page-size="100"
134
+ layout="total, prev, pager, next"
135
+ :total="1000">
136
+</el-pagination>
137
+```
138
+
139
+反例：
140
+```js
141
+<el-pagination
142
+ @size-change="change"
143
+ @current-change="currentChange"
144
+ :current-page.sync="currentPage1"
145
+ :page-size="100"
146
+ layout="total, prev, pager, next"
147
+ :total="1000">
148
+</el-pagination>
149
+```
150
+## 代码规范
151
+【强制】为 v-for 设置键值，在组件上必须用 key 搭配 v-for，以便维护内部组件及其子树的状态。
152
+
153
+【强制】v-if 和 v-for 互斥，永远不要把 v-if 和 v-for 同时用在同一个元素上。
154
+
155
+【强制】多个 attribute 的元素应该分多行撰写，每个 attribute 一行。视情况而定
156
+
157
+【强制】模板中简单的表达式，组件模板应该只包含简单的表达式，复杂的表达式则应该重构为计算属性或方法。
158
+
159
+复杂表达式会让你的模板变得不那么声明式。我们应该尽量描述应该出现的是什么，而非如何计算那个值。而且计算属性和方法使得代码可以重用。
160
+
161
+【强制】指令缩写
162
+
163
+用 : 表示 v-bind:
164
+
165
+用 @ 表示 v-on:
166
+
167
+用 # 表示 v-slot
168
+
169
+【推荐】不同逻辑、不同语义、不同业务的代码之间插入一个空行分隔开来以提升可读性。
170
+
171
+【推荐】条件判断能使用三目运算符和逻辑运算符解决的，就不要使用条件判断，但不要写太长的三目运算符。如果超过 3 层请抽成函数，并写清楚注释。
172
+
173
+【推荐】慎用 console.log，因 console.log 大量使用会有性能问题，调试完最终提交前清除掉
174
+
175
+## 注释规范
176
+注释的原则：提高代码的可读性，从而提高代码的可维护性
177
+如无必要，勿增注释 ( As short as possible )
178
+如有必要，尽量详尽 ( As long as necessary )
179
+
180
+1、HTML 文件注释
181
+
182
+【推荐】单行注释:一般用于简单的描述，如某些状态描述、属性描述等。注释内容前后各一个空格字符，注释位于要注释代码的上面，单独占一行。
183
+
184
+2、模块注释
185
+
186
+【推荐】一般用于描述模块的名称以及模块开始与结束的位置。 注释内容前后各一个空格字符
187
+
188
+## 扩展规范
189
+
190
+1、主题扩展
191
+
192
+【强制】对页面顶部，侧边栏，菜单等公共模块的扩展
193
+
194
+需独立新增app内扩展，可以单独自行安装卸载，以免影响全局
195
+
196
+2.【推荐】扩展名称使用应用名称+菜单名+功能名称
197
+
198
+正例：iot_iiot_program_menu_search_extend
199
+
200
+反例：unit_test_extend_view 不明确生效的位置和功能
201
+
202
+3、样式扩展
203
+
204
+【强制】对框架使用的Element的样式修改时，使用局部作用域，以免影响全局样式
205
+
206
+4、关于扩展选择的节点id
207
+
208
+【强制】在选择扩展的节点id时，对于id中包含undefined的节点不能直接扩展，请咨询平台人员
209
+
210
+5、关于扩展注释
211
+
212
+【推荐】在对某节点扩展时，补充注释信息，说明页面节点，功能描述等信息，方便阅读、定位
213
+
214
+# 版本管理规范
215
+
216
+## 关于版本更新
217
+为了确保线上使用的依赖版本与开发时的版本一致，有以下几项注意事项：
218
+
219
+1、执行npm run update:tech、npm run update:beta、npm update等命令升级后依赖版本中会带有 ^ 等符号，如果需要使用固定版本，需要手动修删除 ^ 符号，使用固定的具体的版本号，并执行npm run init:tech重新安装指定版本
220
+正例：
221
+
222
+```json
223
+// 固定(指定)的版本号
224
+{
225
+ "dependencies": {
226
+ "@tech/t-base": "1.0.11",
227
+ "@tech/t-build": "1.0.1",
228
+ "@tech/t-core": "1.0.9",
229
+ "@tech/t-el-ui": "1.0.9",
230
+ }
231
+}
232
+```
233
+反例：
234
+
235
+```json
236
+// 不固定的版本号，（不推荐）
237
+{
238
+ "dependencies": {
239
+ "@tech/t-base": "^1.0.11",
240
+ "@tech/t-build": "^1.0.1",
241
+ "@tech/t-core": "^1.0.9",
242
+ "@tech/t-el-ui": "^1.0.9",
243
+ }
244
+}
245
+```
246
+
247
+2、为了保证打包稳定，请直接使用当前开发环境所安装的依赖，不需要执行 npm run update:tech 或者 npm run update:beta
248
+
249
+# 工程结构规范
250
+
251
+## 工程结构说明
252
+```js
253
+|— apps
254
+ |— base // 业务App 根据实际情况命名
255
+ |— common // 公共总扩展，一般情况不用操作，后面会展开讲解
256
+ |— common - 公共总扩展
257
+ |— assetImport.js - 内部导入连接资源扩展入口
258
+ |— asset.json - 外部url连接资源扩展入口
259
+ |— common.js - 应用公共配置扩展入口
260
+ |— comps.js - 定制组件扩展入口
261
+ |— extendView.js - 合并视图扩展入口
262
+ |— hook.js - 功能钩子扩展入口
263
+ |— schema.js - 初始视图结构扩展入口
264
+ |— index.js - 公共扩展总入口
265
+ |— views // 纯js格式编辑视图，通过视图的扩展能力合并的主视图中
266
+ |— rbacUser // 业务定制的扩展视图，名称根据实际情况定义
267
+ |— tview__base__rbac_user.js // 扩展文件，后面会展开讲解 命名规则：[自定义业务名].js
268
+ |— ...
269
+ |— index.js // 扩展视图的入口
270
+ |— config // 当前App的额外配置，如全局变量
271
+ |— app.json
272
+ |— resource // 语言包，皮肤 等资源
273
+ |— static-resource // 静态资源
274
+ |— index.js // 扩展引入入口
275
+ |— component // 公共业务组件
276
+|— config
277
+ |— nginx
278
+ |— apps.json
279
+|— build // 各种环境的打包入口
280
+```
281
+工程运行起来后，以下文件夹是工程临时生成文件不用处理：
282
+resource、static-resouorce、views、dist、distApp、distTmp
283
+
284
+## 资源引入规范
285
+1、资源引入
286
+
287
+【强制】前端依赖的第三方库，或组件库的资源地址引入需要做以下配置：
288
+
289
+外部资源需要在./apps/[自己的扩展应用]/common/assets.json配置引入
290
+
291
+内部资源需要在./apps/[自己的扩展应用]/common/assetsImport.js配置引入
292
+
293
+2、资源扩展
294
+
295
+asset.json资源引入扩展，会根据定义里面的 title 作为唯一标识覆盖合并
296
+
297
+assetImport.js资源引入扩展，会根据定义里面的 key 值作为唯一标识覆盖合并， 例如上面的 assetImport.js 引入组件库的key值为 my-ui。
298
+
299
+# 部署规范
300
+
301
+1、底座的更新只能通过更新服务器中前端工程。
302
+
303
+2、app 的更新可通过应用市场更新，可也以通过服务器部署更新
304
+
305
+3、打包外部依赖 app 和本地开发的 app 到./dist/umdComps中。适用于通过应用市场上传安装
306
+
307
+【强制】主服务器的 nginx 需要增加允许跨域
308
+
309
+1、所有的涉及静态资源转发的都需要配置允许跨域
310
+
311
+2、涉及代理转发的不需要设置跨域
web-front-standard.md
... ...
@@ -1,311 +0,0 @@
1
-<!--[[_TOC_]]-->
2
-# IIDP前端开发规范
3
-
4
-[[http://192.168.175.198:10003/iidpminio/home/logo.png]]
5
-
6
-# 前言
7
-
8
-希望IIDP开发者通过阅读本手册，能够充分利用IIDP平台进行开发，避免常见的错误和陷阱，写出高质量的代码，提高开发效率。让我们一起码出高效、码出质量的软件系统。
9
-
10
-# 开发规范
11
-
12
-## 命名规范
13
-
14
-### 项目文件命名
15
-
16
-1、项目文件名
17
-
18
-【推荐】命名方法：kebab-case 字母小写短横线连接
19
-
20
-正例：whclould-smart-port / my-project-name
21
-
22
-反例：My-Project
23
-
24
-2、目录名
25
-
26
-【推荐】有复数结构时，要采用复数命名法
27
-
28
-正例：assets、components、directives、mixins、utils、views
29
-
30
-### 组件命名
31
-
32
-1.【强制】 组件命名规范，组件名称必须唯一
33
-
34
-说明：在IIDP平台中，确保组件名称的唯一性，便于识别和管理。 tech-作为名称前缀，具体的组件名作为后缀名称。
35
-
36
-正例：tech-button / tech-dialog / tech-upload / tech-custom-multi-input 使用时type：button
37
-
38
-反例：custom-multi-input 没有tech-作为名称前缀，会导致使用时type：custom-multi-input不显示这个组件
39
-
40
-
41
-2、单文件组件名
42
-
43
-【推荐】单文件组件名应该始终是单词大写开头 (PascalCase)，大驼峰式命名法。
44
-
45
-正例：CustomComponent.vue
46
-
47
-反例：my-Component.vue
48
-
49
-3、基础组件名
50
-
51
-【推荐】基础组件在一个页面内可使用多次，在不同页面内也可复用，是高可复用组件。应该全部以一个特定的前缀开头 —— Base
52
-
53
-正例：BaseButton.vue/ BaseInput.vue
54
-
55
-反例：myButton.vue
56
-
57
-4、业务组件
58
-
59
-【推荐】掺杂了复杂业务的组件（拥有自身 data、prop 的相关处理）即业务组件应该以 Custom 前缀命名。
60
-
61
-正例：CustomCard.vue
62
-
63
-反例：myCard.vue
64
-
65
-5、组件名中单词顺序
66
-
67
-【推荐】组件名应该以高级别的 (通常是一般化描述的) 单词开头，以描述性的修饰词结尾。组件名尽量以完整单词命名，单词尽量语义化，方便阅读。
68
-
69
-正例：SearchContent.vue
70
-
71
-反例：ContSech.vue
72
-
73
-### 代码参数命名
74
-1、【推荐】在声明 prop 的时候，其命名应该始终使用 camelCase(小驼峰式命名)，而在模板和 JSX 中应该始终使用 kebab-case(短横线连接式)。我们单纯的遵循每个语言的约定，在 JavaScript 中更自然的是 camelCase。而在 HTML 中则是 kebab-case
75
-
76
-正例：camelCase
77
-
78
-反例：camel-Case
79
-
80
-2、router属性
81
-
82
-【推荐】Vue Router Path 命名采用 kebab-case (短横线连接式)格式。或者PascalCase(大驼峰命名)，推荐使用kebab-case 短横线。 用 Snake(下划线连接式)（如：/user_info）或 camelCase(小驼峰命名)（如：/userInfo)的单词会被当成一个单词，搜索引擎无法区分语义
83
-
84
-3、模板中组件
85
-
86
-对于绝大多数项目来说，在单文件组件和字符串模板中组件名应该总是 PascalCase(大驼峰命名) 的，但是在 DOM 模板中总是 kebab-case (短横线连接式)的。
87
-
88
-4、全局变量，全局方法名称使用应用名称+功能名称
89
-
90
- 正例:
91
-```js
92
- const IOT_THEME_OPTIONS = ['blue', 'red', 'green']
93
-
94
- function iotGetSearchParams(params){
95
- console.log(params)
96
- }
97
-```
98
-
99
-反例： const MY_TE = ['blue', 'red', 'green']
100
-
101
-5、变量
102
-
103
-命名规范：类型 + 对象描述或属性的方式
104
-
105
-正例：camelCase
106
-
107
-6、常量
108
-
109
-命名规范：使用大写字母和下划线来组合命名，下划线用以分割单词，力求语义表达完整清楚
110
-
111
-正例：const MAX_COUNT = 10 //全部大写下划线分割
112
-
113
-反例： const MC = 10
114
-
115
-7、方法
116
-
117
-命名规范：统一使用动词或者动词 + 名词形式
118
-
119
-正例：jumpPage、loginIn、openDialog、getListApi、refresh
120
-
121
-反例：pageGet
122
-
123
-8、事件方法
124
-
125
-命名规范：handle + 名称（可选）+ 动词
126
-
127
-正例：
128
-```js
129
-<el-pagination
130
- @size-change="handleSizeChange"
131
- @current-change="handleCurrentChange"
132
- :current-page.sync="currentPage"
133
- :page-size="100"
134
- layout="total, prev, pager, next"
135
- :total="1000">
136
-</el-pagination>
137
-```
138
-
139
-反例：
140
-```js
141
-<el-pagination
142
- @size-change="change"
143
- @current-change="currentChange"
144
- :current-page.sync="currentPage1"
145
- :page-size="100"
146
- layout="total, prev, pager, next"
147
- :total="1000">
148
-</el-pagination>
149
-```
150
-## 代码规范
151
-【强制】为 v-for 设置键值，在组件上必须用 key 搭配 v-for，以便维护内部组件及其子树的状态。
152
-
153
-【强制】v-if 和 v-for 互斥，永远不要把 v-if 和 v-for 同时用在同一个元素上。
154
-
155
-【强制】多个 attribute 的元素应该分多行撰写，每个 attribute 一行。视情况而定
156
-
157
-【强制】模板中简单的表达式，组件模板应该只包含简单的表达式，复杂的表达式则应该重构为计算属性或方法。
158
-
159
-复杂表达式会让你的模板变得不那么声明式。我们应该尽量描述应该出现的是什么，而非如何计算那个值。而且计算属性和方法使得代码可以重用。
160
-
161
-【强制】指令缩写
162
-
163
-用 : 表示 v-bind:
164
-
165
-用 @ 表示 v-on:
166
-
167
-用 # 表示 v-slot
168
-
169
-【推荐】不同逻辑、不同语义、不同业务的代码之间插入一个空行分隔开来以提升可读性。
170
-
171
-【推荐】条件判断能使用三目运算符和逻辑运算符解决的，就不要使用条件判断，但不要写太长的三目运算符。如果超过 3 层请抽成函数，并写清楚注释。
172
-
173
-【推荐】慎用 console.log，因 console.log 大量使用会有性能问题，调试完最终提交前清除掉
174
-
175
-## 注释规范
176
-注释的原则：提高代码的可读性，从而提高代码的可维护性
177
-如无必要，勿增注释 ( As short as possible )
178
-如有必要，尽量详尽 ( As long as necessary )
179
-
180
-1、HTML 文件注释
181
-
182
-【推荐】单行注释:一般用于简单的描述，如某些状态描述、属性描述等。注释内容前后各一个空格字符，注释位于要注释代码的上面，单独占一行。
183
-
184
-2、模块注释
185
-
186
-【推荐】一般用于描述模块的名称以及模块开始与结束的位置。 注释内容前后各一个空格字符
187
-
188
-## 扩展规范
189
-
190
-1、主题扩展
191
-
192
-【强制】对页面顶部，侧边栏，菜单等公共模块的扩展
193
-
194
-需独立新增app内扩展，可以单独自行安装卸载，以免影响全局
195
-
196
-2.【推荐】扩展名称使用应用名称+菜单名+功能名称
197
-
198
-正例：iot_iiot_program_menu_search_extend
199
-
200
-反例：unit_test_extend_view 不明确生效的位置和功能
201
-
202
-3、样式扩展
203
-
204
-【强制】对框架使用的Element的样式修改时，使用局部作用域，以免影响全局样式
205
-
206
-4、关于扩展选择的节点id
207
-
208
-【强制】在选择扩展的节点id时，对于id中包含undefined的节点不能直接扩展，请咨询平台人员
209
-
210
-5、关于扩展注释
211
-
212
-【推荐】在对某节点扩展时，补充注释信息，说明页面节点，功能描述等信息，方便阅读、定位
213
-
214
-# 版本管理规范
215
-
216
-## 关于版本更新
217
-为了确保线上使用的依赖版本与开发时的版本一致，有以下几项注意事项：
218
-
219
-1、执行npm run update:tech、npm run update:beta、npm update等命令升级后依赖版本中会带有 ^ 等符号，如果需要使用固定版本，需要手动修删除 ^ 符号，使用固定的具体的版本号，并执行npm run init:tech重新安装指定版本
220
-正例：
221
-
222
-```json
223
-// 固定(指定)的版本号
224
-{
225
- "dependencies": {
226
- "@tech/t-base": "1.0.11",
227
- "@tech/t-build": "1.0.1",
228
- "@tech/t-core": "1.0.9",
229
- "@tech/t-el-ui": "1.0.9",
230
- }
231
-}
232
-```
233
-反例：
234
-
235
-```json
236
-// 不固定的版本号，（不推荐）
237
-{
238
- "dependencies": {
239
- "@tech/t-base": "^1.0.11",
240
- "@tech/t-build": "^1.0.1",
241
- "@tech/t-core": "^1.0.9",
242
- "@tech/t-el-ui": "^1.0.9",
243
- }
244
-}
245
-```
246
-
247
-2、为了保证打包稳定，请直接使用当前开发环境所安装的依赖，不需要执行 npm run update:tech 或者 npm run update:beta
248
-
249
-# 工程结构规范
250
-
251
-## 工程结构说明
252
-```js
253
-|— apps
254
- |— base // 业务App 根据实际情况命名
255
- |— common // 公共总扩展，一般情况不用操作，后面会展开讲解
256
- |— common - 公共总扩展
257
- |— assetImport.js - 内部导入连接资源扩展入口
258
- |— asset.json - 外部url连接资源扩展入口
259
- |— common.js - 应用公共配置扩展入口
260
- |— comps.js - 定制组件扩展入口
261
- |— extendView.js - 合并视图扩展入口
262
- |— hook.js - 功能钩子扩展入口
263
- |— schema.js - 初始视图结构扩展入口
264
- |— index.js - 公共扩展总入口
265
- |— views // 纯js格式编辑视图，通过视图的扩展能力合并的主视图中
266
- |— rbacUser // 业务定制的扩展视图，名称根据实际情况定义
267
- |— tview__base__rbac_user.js // 扩展文件，后面会展开讲解 命名规则：[自定义业务名].js
268
- |— ...
269
- |— index.js // 扩展视图的入口
270
- |— config // 当前App的额外配置，如全局变量
271
- |— app.json
272
- |— resource // 语言包，皮肤 等资源
273
- |— static-resource // 静态资源
274
- |— index.js // 扩展引入入口
275
- |— component // 公共业务组件
276
-|— config
277
- |— nginx
278
- |— apps.json
279
-|— build // 各种环境的打包入口
280
-```
281
-工程运行起来后，以下文件夹是工程临时生成文件不用处理：
282
-resource、static-resouorce、views、dist、distApp、distTmp
283
-
284
-## 资源引入规范
285
-1、资源引入
286
-
287
-【强制】前端依赖的第三方库，或组件库的资源地址引入需要做以下配置：
288
-
289
-外部资源需要在./apps/[自己的扩展应用]/common/assets.json配置引入
290
-
291
-内部资源需要在./apps/[自己的扩展应用]/common/assetsImport.js配置引入
292
-
293
-2、资源扩展
294
-
295
-asset.json资源引入扩展，会根据定义里面的 title 作为唯一标识覆盖合并
296
-
297
-assetImport.js资源引入扩展，会根据定义里面的 key 值作为唯一标识覆盖合并， 例如上面的 assetImport.js 引入组件库的key值为 my-ui。
298
-
299
-# 部署规范
300
-
301
-1、底座的更新只能通过更新服务器中前端工程。
302
-
303
-2、app 的更新可通过应用市场更新，可也以通过服务器部署更新
304
-
305
-3、打包外部依赖 app 和本地开发的 app 到./dist/umdComps中。适用于通过应用市场上传安装
306
-
307
-【强制】主服务器的 nginx 需要增加允许跨域
308
-
309
-1、所有的涉及静态资源转发的都需要配置允许跨域
310
-
311
-2、涉及代理转发的不需要设置跨域