https://download.csdn.net/download/weixin_51364599/85122544
用vite初始化的项目与vue-cli基本一样，但是有几个点需要注意一下
1.项目的版本依赖问题
因为获取的是最新的vite和vue，而初始化的项目依赖中也只有vite和vue，
像vuex，ts，router等都是没有的。所以可能有版本上兼容的问题。
这里引用了vuex和vue-router，两者都必须是4.0版本或者以上
这里不建议用最新的vue和vite来构建项目，因为与vuex存在兼容问题，估计得等vuex5出后可以解决
2.vuex和vue-router的新的初始化方法
在vue2中，vuex和vue-router都是以new来构建实例对象，而在4.0后用create函数构建
这里以vuex为例
4.0的vuex依旧保留了store对象，最新的版本已经移除strore，所以老老实实用createStore构建
其实也就是不用new store改用createStore，其他方面和以前一样
下面是vue-router
网上有说要用defineAsyncComponent包裹路由组件，不然会报错。但试了不加后，在开发环境和生产环境也不会报错，这里记录下来以防万一
3.路径别名的设置
与vue-cli有个小区别，vite只能设置完整的路径，例如："components": path.resolve(__dirname, "src/components"),不能和vue-cli一样设置成"components": "@/components"。
设置成"components": "@/components"在开发环境下没有问题，后来发现在生产上却无法正确解析。
总结：打包工具配置，最好还是以官方案例为准
4.vuex和vue-router的使用问题
有两种使用方式，这里以vue-router为例
第一种：
import {useRouter} from "vue-router"
export default {
setup(){
let router = useRouter()//这种方式初始化只能写在setup作用域内
}
}
<script setup>
let router = useRouter()//一样在setup作用域内
</script>
第二种：直接引用实例
import router from "@/router/index.js"
router.push({
path:'/'
})?当然用router-link组件也是可以的
vuex同理
<script>
import {mapState,mapGetters,mapMutations} from 'vuex'
export default {
computed:{
...mapState(["username"]),
...mapGetters(["getUserName"])
},
methods: {
...mapMutations(["SET_USERNAME"])
},
mounted() {
console.log(this.getUserName,'getUserName')
console.log(this.username,'username111')
},
}
</script>
<script setup>
import { ref,computed } from 'vue'
import {useStore} from 'vuex'
defineProps({
msg: String
})
const count = ref(0)
let add = computed(()=>{
return count.value+1
})
let store = useStore()
console.log(add.value,'add');
console.log(store.state.username);
</script>?这里的map函数只能用在老写法中，新的setup写法不支持
项目后续还需要加上css处理和axios
5.setup语法糖注意事项
?
<script setup>
import { ref,computed,reactive } from 'vue'
const username = ref("hahahah")//这里的响应式优先级比下面的username高
</script>
<script>
export default {
data(){
return { username:"11111" }
},
mounted() {
console.log(this.username,'username111')
},
}
</script>
?setup写法和普通组件配置写法会有覆盖情况，应该避免出现同名覆盖
setup内的username响应式优先级更高，即{{username}}是‘hahahah’
mounted下的username在build环境下是打印11111，dev环境下打印‘hahahah’
结论：同名存在覆盖情况，同名情况下响应式优先级以setup内的准，推测不同作用域内存在有两个不同的username，响应式绑定以执行顺序有关，先执行setup函数，再去初始化data
