欢迎来到皮皮网官网
1.����appԴ��
2.人人商城app打包封装教程最新版方法含支付分享等功能
3.app打包是帮打包a包平什么意思
4.一次vue-cli4项目升级到vite的经历
5.简简单单将Java应用封装成Docker镜像
����appԴ��
本文介绍使用pyinstaller配合nuitka打包Python程序的详细步骤和策略。在软件版本上，源码推荐使用pyinstaller6.3.0和nuitka2.0.3，台源已经通过win7和win的帮打包a包平测试。在打包过程中，源码使用pyinstxtractor.py解包，台源易安卓取网页源码且源码均经过加密处理。帮打包a包平
首先，源码了解Python程序打包的台源两种常见方式：pyinstaller和nuitka。其中，帮打包a包平pyinstaller在打包速度和成功率方面有显著优势，源码但运行速度相较于nuitka要慢一些，台源且代码存在被破解的帮打包a包平风险。nuitka则在运行速度上表现优秀，源码但打包过程可能较慢，台源成功率也相对较低。
本文推荐的打包方法是，先使用nuitka将代码编译为pyd文件，pyd文件通过预编译和底层编程语言的使用，能极大地减少运行时的开销，从而提高程序执行速度。然后，使用pyinstaller对整个项目进行打包。
在实现过程中，需要完成以下步骤：
1. 准备工作：确保环境安装了pyinstaller和nuitka，同时切换到项目目录下。
2. 使用nuitka将app文件夹中的所有py文件转换为pyd模块文件，同时生成包含import信息的pyi文件。生成的文件包括app.cp-win_amd.pyd（包含所有程序代码，但不包含资源文件）和app.pyi（包含import信息）。
3. 将生成的pyd文件导入信息添加到main.py文件中，通过复制或使用isort工具整理import语句。
4. 使用pyinstaller打包main.py文件，生成的程序将保留部分代码作为二进制文件（pyd），同时main.py文件内容尽量保持简单，以避免被轻易破解。
5. 对打包后的程序进行体积优化，使用自编脚本减少程序大小，通常能优化%~%。
此打包方式结合了nuitka的高性能和pyinstaller的快速打包特点，但牺牲了程序启动速度。Virtual框架源码对于更进一步优化启动速度的需求，可以参考后续文章中提到的嵌入式打包方法。
为了帮助理解和实践打包过程，文中提供了相关视频讲解资源，包括“pyinstaller配合nuitka打包，发布Python程序”和“python打包程序瘦身”等内容。在遇到解决不了的问题时，欢迎咨询。
人人商城app打包封装教程最新版方法含支付分享等功能
对于寻求低成本电商应用解决方案的小企业和个人用户，人人商城和变色龙云这类平台的兴起降低了开发和部署成本，使得它们成为众多选择中的一款热门选项。 首先，获取人人商城源码后，通过网上的教程搭建商城网站是基础步骤。本文将重点讲解如何利用变色龙云在线打包平台实现app封装，包括支付和分享功能的集成。准备工作
搭建人人商城网站
下载并安装人人商城app插件
在变色龙云注册账号
配置微信、微博等第三方平台接口（可选，用于支付、分享等）
后台配置与安装插件
启用人人商城的多端访问和支付功能
安装app插件，覆盖到后台
配置支付、分享和登录功能
确保兼容性设置，如UA类型匹配
常见问题与解决方法
检查支付与登录显示问题，可能需要自定义UA
微信登录问题，需替换特定目录文件
支付宝回调问题，可能涉及证书或代码修改
支付宝支付错误时，检查notify.php中的相关代码
配置后App空白，删除特定CSS样式
通过以上步骤，你已经掌握了人人商城app打包封装的最新方法。在变色龙云后台的详细配置流程可能被省略，遇到问题可查看帮助教程或留言交流。app打包是什么意思
App打包是指将应用程序的各个组件、源代码、资源文件等整合成一个可发布的安装包的过程。 接下来详细解释这一概念： 1. App打包的基本含义 App打包是将一个应用程序的所有相关文件，包括代码、资源、图像、配置文件等，整合成一个安装文件的firefox源码config过程。这个安装文件可以被用户下载并安装到他们的设备上，以使用应用程序提供的各项功能。打包的目的是为了方便分发和安装，确保应用程序能在不同的设备和操作系统上正常运行。 2. 打包过程的重要性 在开发过程中，开发者会不断地对应用程序进行测试和修改。当应用准备好发布时，就需要进行打包，以确保最终用户下载的是一个完整且无误的应用。此外，打包还可以帮助开发者针对不同的设备和操作系统进行适配和优化，以确保应用的兼容性和性能。 3. 打包的具体步骤和内容 App打包通常涉及多个步骤，包括清理不必要的文件、整合源代码和资源文件、配置必要的设置、生成安装文件等。打包工具会根据开发者的需求和应用的特性进行自动或半自动的处理。生成的安装文件通常是一个包含所有必要文件和设置的压缩包，用户可以通过下载并安装这个包来使用应用程序。打包后的应用通常还会经过测试以确保其功能和性能的正常。同时，打包过程还需要考虑应用的发布渠道和市场需求，如适配不同的操作系统版本、屏幕尺寸等。最终生成的安装包可以用于在各种应用商店或平台上发布，供用户下载和使用。通过这种方式，开发者可以将自己的创意转化为具体的应用服务，满足广大用户的需求。一次vue-cli4项目升级到vite的经历
背景
使用vue-cli4的项目，业务写多了之后开发运行和打包都慢了很多，为了提升开发体验以及更新团队技术框架，需要升级到更高级的脚手架上，两种方案：一是升级到vue-cli5，二是升级到最新的vite。
其中第一种方案升级简单，经过实验，打包的速度不升反慢，这可能和项目中的韭菜盘源码有依赖以及业务代码有关。
第二种方案升级vite，经过可行性调查，升级到vite的成功率非常高，最后决定从vue-cli4升级到vite，这是一个高风险高回报的事情，因为尽管市面上已存在很多升级成功的案列，但是每个项目都不一样，我们的项目也很庞大，依赖很多，并没有%升级成功的把握。而升级成功的回报也很显而易见，开发环境几乎秒运行，开发体验得到了显著提升。
升级前后对比||vue-cli4|vite||---|---|---||开发启动时间|ms|ms||生产打包时间|s|s||打包体积|.6MB|.6MB||运行期间同一代码改动编译时间|ms|瞬时|
生产环境打包时间可能和我们项目中用到了太多vite插件有关系，但开发环境的提升非常显著。
项目状况项目中用到的Vue2，VueCli版本：4.5.，版本更新时间为.5.8，vueCli4的最后版本为4.5.(.3.)，依赖的webpack版本为^4.0.0
组件库使用vant，依赖Less预处理器，通过vue.config.js配置设置了less主题色，在webpack仅支持less-loader@5版本以及对应的less版本
业务css预处理器为stylus:"^0..5"，对应stylus-loader:"^3.0.2"
进行了多页打包（MPA）
使用了workbox-webpack-plugin插件配置了PWA：WorkboxWebpackPlugin
配置了多个路径映射（alias别名）
指定了文件输出路径以及hash配置
生产环境下关闭productionSourceMap以及css的sourceMap提升打包速度
proxy开启多个代理
用到了.env文件中的环境变量
按照开发规范忽略部分文件后缀以及index.js
移除了preload脚本
期望结果可以使用vite进行开发和打包
仍保留webpack打包功能（因为项目太大，不能保证升级到vite后会不会有问题，所以仍希望webpack原本功能正常运行）
准备工作升级Node版本，vite只支持node及以上，建议升级到v以上。
安装pnpm工具，pnpm作为更好的npm依赖管理工具，是目前npm和yarn的最好替代品，且有些依赖包使用npm安装时会有异常，使用pnpm安装可解决：pnpm
小项目尝试一键转换升级：wp2vite、webpack-to-vite，这两个工具都提供了一键将webpack项目转成vite的能力，但对于大中型项目，并不可靠。
开始行动1.安装必要依赖pnpm?add?vite-plugin-env-compatible?vite-plugin-html?vite?vite-plugin-vue2?--devvite-plugin-vue2是处理vue2版本代码的插件，如果项目中是vue3，安装的谷歌kotlin源码依赖有所不同，请参考webpack-to-vite
2.复制html到根目录，并修改 注意是复制，并只改动复制后的html，这样才不会破坏原有webpack功能。修改复制后的html，增加对应的js文件引用，注意type属性不能少！
<!--?忽略一些代码?--><body><div?id="app"></div>++?<script?type="module"?src="/src/main.js"></script>?++</body>多页打包(MPA)，其他页面的html同样操作，不同html引入对应的js即可。
3.新增vite.config.js文件，开始迁移最重要的配置部分空配置如下：
import?{ ?defineConfig?}?from?'vite'export?default?defineConfig({ })4.修改环境变量环境变量主要面临两个问题：
要兼容webpack和vite的环境变量用法
解决方法：使用vite插件vite-plugin-env-compatible，让vite中可以使用webpack中读取环境变量的方式，再配合envPrefix配置，让vite可以读取到VUE_APP_开头的环境变量：
?pnpm?add?vite-plugin-env-compatible?-D?import?{ ?defineConfig?}?from?'vite'?import?envCompatible?from?'vite-plugin-env-compatible'?export?default?defineConfig({ plugins:?[?envCompatible()],envPrefix:?['VUE_APP_']?//?很重要?})?//?mian.js测试?console.log(process.env.VUE_APP_UNION_STATS)?console.log(import.meta.env.VUE_APP_UNION_STATS)两个打印都得到了正确的结果，注意：vite中默认只能读取到VITE_开头的环境变量，如果不配置envPrefix，则会导致第二个打印为undefind。
vite.config.js中不能读取到环境变量
vite.config.js是无法直接通过import.meta.env和process.env获取环境变量的，我们需要通过vite的loadEnv获取。
我们需要将vite.config.js的导出对象改为函数：
?import?{ ?defineConfig,loadEnv?}?from?'vite'?export?default?({ ?mode?})?=>?{ ?const?isPro?=?mode?===?'production'?//?我们可以通过mode直接判断当前是不是生产环境，注意mode可以在运行指令中指定：`vite?build?--mode?master`，如果没有指定，那默认打包就是production?function?getEnv(key)?{ ?//?定义获取环境变量的方法?return?loadEnv(mode,?process.cwd(),'')[key]?//?第三个参数非常重要，下面有详解?}?return?defineConfig({ ?base:?getEnv('VUE_APP_PUBLICPATH'),?//?读取环境变量?//?...忽略其他代码?})?})loadEnv有三个参数，前两个参数基本固定不变，而第三个参数默认情况下是不需要传的，只有在配置了envPrefix项，读取非VITE_开头的变量时才需要，在loadEnv源码中我们可以看到，第三个参数是prefixes:string|string[]='VITE_'，也就是环境变量的前缀，默认是VITE_。
如果你的项目和我一样，读取了VUE_APP_PUBLICPATH这样非VITE_开头环境变量，就在loadEnv的第三个参数传递空字符串即可，这样就能读取到所有的环境变量了。
5.兼容commonjs代码项目中有用到commonjs规范的依赖，比如letmd5=require('js-md5').create()，webpack是基于node开发的，支持require语法，在打包的时候webpack也会正确处理这部分代码，但在vite中不会，所以需要将这部分代码改成importmd5from'js-md5'
项目开发环境下，一些node_modules中的包也会存在commonjs的代码，我们可以通过vite的插件?vite-plugin-commonjs来实现这部分代码的转化，保证开发环境的正常运行。
pnpm?add?@originjs/vite-plugin-commonjs?--dev//?vite.config.js?忽略其他代码import?{ ?viteCommonjs?}?from?'@originjs/vite-plugin-commonjs'export?default?({ ?mode?})?=>?{ return?defineConfig({ plugins:?[//?...viteCommonjs()?//?兼容vite中的cjs导入语法]})})6.解决css预处理的问题vite内置了对主流css预处理器的支持（sass/less/stylus），项目使用预处理器时，只需要安装对应预处理依赖即可：
#?.scss?and?.sasspnpm?add?sass?-D#?.lesspnpm?add?stylus?-D#?.styl?and?.styluspnpm?add?stylus?-D比较巧的是，我们项目中用到的Stylus的@import别名的语法和vite冲突，@import'~@/public/stylus/mixins'这样的代码是会报错，一开始我找到了插件，可以帮助我们解决这个问题：vite-plugin-stylus-alias，但是都后面打包的时候发现这个插件有副作用，后面采取了其他方法解决。
<!--?忽略一些代码?--><body><div?id="app"></div>++?<script?type="module"?src="/src/main.js"></script>?++</body>0<!--?忽略一些代码?--><body><div?id="app"></div>++?<script?type="module"?src="/src/main.js"></script>?++</body>1使用这个插件会导致无法生成sourcemap文件，在打包的时候可以看到警告：Sourcemapislikelytobeincorrect:aplugin(vite-plugin-stylus-alias)wasusedtotransformfiles,butdidn'tgenerateasourcemapforthetransformation.Consulttheplugindocumentationforhelp，鉴于插件作者已经很久没有更新，建议能改成相对路径还是直接改，如果引用地方较多，可以定义文件为全局styl文件最新解决方案：一般出现这个报错是因为插件使用了vite的transformapi转换代码，但是return值缺失导致，解决方法：复制插件代码到项目中，在插件transform函数return的结果中，返回map:null，然后再vite.config.js中引用项目中修改后的插件，即可完美解决，如下：文末解决bug有细说
<!--?忽略一些代码?--><body><div?id="app"></div>++?<script?type="module"?src="/src/main.js"></script>?++</body>2定义stylus全局文件
<!--?忽略一些代码?--><body><div?id="app"></div>++?<script?type="module"?src="/src/main.js"></script>?++</body>3这里需要注意，官方文档中css-preprocessoroptions写的是使用文件名拓展名作为key，stylus的文件拓展名是styl，但是我使用了stylus作为key并不会有问题，相反使用styl作为key则不生效了，后续这个地方可以留意一下。
在vite源码中，stylus和styl都进行了判断，理论上都可以使用，但目前测试的结果就是styl作为key不生效，可能源码中其他地方还能找到原因。
7.组件库按需导入和定制主题我们项目中用到的组件库是Vant2，该组件库依赖Less，以及通过配置文件来定制组件的主题，在配置中我们需要进行修改：
vue-cli中的主题配置部分如下：
<!--?忽略一些代码?--><body><div?id="app"></div>++?<script?type="module"?src="/src/main.js"></script>?++</body>4vite中主题配置部分如下：
<!--?忽略一些代码?--><body><div?id="app"></div>++?<script?type="module"?src="/src/main.js"></script>?++</body>5按需导入项目中按需导入vant组件库，组件可以成功导入，但是组件的样式缺失了，这是因为在webpack中，babel-plugin-import插件帮我们实现了组件的样式导入，在vite中使用?vite-plugin-style-import插件帮我们实现这个功能，不仅vant组件库，其他诸如element、antv等组件库也可以使用这个插件进行按需导入：
<!--?忽略一些代码?--><body><div?id="app"></div>++?<script?type="module"?src="/src/main.js"></script>?++</body>6<!--?忽略一些代码?--><body><div?id="app"></div>++?<script?type="module"?src="/src/main.js"></script>?++</body>.修改alias别名配置，以及忽略文件后缀vite配置别名的方法和vue-cli有所不同，且没有默认的别名，都需要通过配置实现，且vite默认不能忽略文件后缀导入，我们也需要通过修改配置来实现：
<!--?忽略一些代码?--><body><div?id="app"></div>++?<script?type="module"?src="/src/main.js"></script>?++</body>8需要注意extensions配置的顺序，从左到右进行匹配，如果存在同名但类型不同的文件，很可能得到期望外的结果，比如同目录下存在index.js和index.vue，按上面的顺序，import'./index?会优先匹配到index.js文件。这种情况建议补全后缀进行导入。
9.配置前端跨域vite配置跨域和webpack也有出入，需要修改配置
<!--?忽略一些代码?--><body><div?id="app"></div>++?<script?type="module"?src="/src/main.js"></script>?++</body>9以上就是几种常见的跨域配置方式，webpack中的devServer改为了server,webpack的proxy中的pathRewrite改成了rewrite，并且类型成为了函数，在函数中返回请求的路径即可。
.多页打包以及打包的其他配置vite在build.rollupOptions配置多页打包，参考rollupOptions，其他配置参考文档
import?{ ?defineConfig?}?from?'vite'export?default?defineConfig({ }).配置运行路径base是指项目运行在服务器的哪个路径下，一般通过从环境变量中动态获取。
import?{ ?defineConfig?}?from?'vite'export?default?defineConfig({ }).配置EsLintvite中使用vite-plugin-eslint插件实现eslint的检查功能，安装过程中发现vite-plugin-eslint@1.4.0会报错，安装1.3.0版本即可。
import?{ ?defineConfig?}?from?'vite'export?default?defineConfig({ })2import?{ ?defineConfig?}?from?'vite'export?default?defineConfig({ }).使用插件@vitejs/plugin-legacy兼容低版本浏览器plugin-legacy文档
import?{ ?defineConfig?}?from?'vite'export?default?defineConfig({ }).配置运行指令import?{ ?defineConfig?}?from?'vite'export?default?defineConfig({ })5可以在指令中声明mode环境，这个mode在vite.config.js中可以得到，具体可以参考前面4.修改环境变量
保存运行指令npmrunserve开发环境已经可以跑起来了，但是vite的特性是你用到的页面才会进行打包，其他页面没有进行访问，是不会打包的，所以需要进行打包才能知道其他地方改造会不会有问题，打包如果有报错，再解决报错即可。
.解决报错globalisnotdefined
这个错误是在node_modules/buffer/index.js?v=ea7文件中抛出的，我查看了yarn.lock文件，依赖路径为多个vue-cli插件>webpack@4.0.0>node-libs-browser?>buffer
这个是依赖的问题，第一删除node_modules重新安装依赖。第二更换npm工具为pnpm重装依赖，如果仍不行，建议不建议webpack，删除掉webpack相关依赖。
网上还有一种做法是：在window对象上挂载global对象，可作为备选方案。
import?{ ?defineConfig?}?from?'vite'export?default?defineConfig({ })6@import'~@vant/icons/src/encode-woff2.less';报错
这个错误是vant组件库中的icon组件抛出的，vite默认不能使用别名，我们在前面配置了别名，但是配置的是~@指向项目中的src目录，这样vant组件库的这个文件引用就找不到了。
issuesvant
解决方法：针对vant的这个文件，做一个别名，放到第一位，优先进行匹配：
import?{ ?defineConfig?}?from?'vite'export?default?defineConfig({ })7运行vitebuild，css产生了一些警告。
警告分为两种，一是css中的属性拼写错误，诸如：color写成了colo，background写成了backgrounc，属于语法错误，根据警告提示搜索对应样式进行修改即可。
二是一些语法正确，但还不清楚为什么压缩时提示了警告：比如stylus修改scoped样式用的>>>语法，以及background?rgba(0,0,0,0.5)提示Unexpected"rgba("。
Thepackagemayhaveincorrectmain/module/exportsspecifiedinitspackage.json
这个错误是通过npminstall后运行vite指令报错的，用yarn安装一直很正常，原因是node_modules的某个包的package.json定义的main入口路径错了，所以找不到模块导入。
解决方法：针对这个模块，定义别名，指向正确的入口：
import?{ ?defineConfig?}?from?'vite'export?default?defineConfig({ })8打包后导入函数定义别名后，调用函数报错
import*asminByfrom'lodash.minby'代码报错了，而且只有在生产环境下才产生。
解决方法：暂时去掉别名，这应该和lodash的导出方式modules.export在vite中转化成ES语法的过程有关系。
importminByfrom'lodash.minby'
requireisnotdefine，通过require导入资源报错
前面在步骤5已经用了插件vite-plugin-commonjs转化common.js的代码了，require理应不会报错。
但是require导入资源算是webpack的功能，和js代码不一样，所以导入资源的代码都要进行修改：
require('./images/logo.png')改成importlogofrom'./images/logo.png'
这样的修改可以兼容webpack和vite，这是在现有项目中，改动的地方会达到上百处，非常麻烦。
简简单单将Java应用封装成Docker镜像
想必Docker这个词大家都不陌生，是一个非常优秀的虚拟化容器。我的博客
怎么把Java应用打包成Docker镜像？对熟悉Docker的同学这应该是一个很简单的问题，把项目打包成JAR包然后在Dockerfile里用ADD命令把JAR文件放到镜像里，启动命令设置执行这个JAR文件即可。
可是对于不懂Java的，听起来貌似并不是那么简单。
在这之前，我们先了解了解什么是：Dockerfile。
DockerfileDockerfile 是一个用来构建镜像的文本文件，文本内容包含了一条条构建镜像所需的指令和说明。
比如一个使用Maven构建的Spring应用就可以用下面这个Dockerfile构建镜像。
FROM openjdk:8-jre ADD target/*.jar /application.jar ENTRYPOINT ["java", "-jar","/application.jar"]咦？这是啥语言，也没见过啊？这个其实是dockerfile的指令。
上面这个Dockerfile的指令很好理解，使用Maven构建的Java项目的目录结构统一是：
project │ pom.xml └───src // 源文件目录 │ │ │ └───main │ ││ └───java │└───target // class和jar文件的目录用mvn clean package打包后会把JAR文件生成在target目录里，通过java -jar命令即可执行编译好的程序。
所以上面的Dockerfile里就进行了把JAR从target目录里添加到Docker镜像中以及将jar -jar /application.jar 设置成容器的启动命令这两步操作。
不过除了这种最原始的方法外我们还可以使用Maven的一些插件，或者Docker的多阶段打包功能来完成把Java应用打包成Docker镜像的动作。
Maven插件构建镜像Spotify公司的dockerfile-maven-plugin和Google公司出品的jib-maven-plugin是两款比较有名的插件，下面简单介绍一下dockerfile-maven-plugin的配置和使用。
其实使用方法很简单，我们在POM文件里引入这个plugin，并结合上面那个Dockerfile就能让插件帮助我们完成应用镜像的打包。
<groupId>com.example</groupId> <artifactId>hello-spring</artifactId> <version>0.0.1-SNAPSHOT</version> <name>helloworld</name> <plugin><groupId>com.spotify</groupId><artifactId>dockerfile-maven-plugin</artifactId><version>1.4.</version><executions> <execution> <id>default</id> <goals> <goal>build</goal> <goal>push</goal> </goals> </execution> </executions> <configuration> <repository>${ docker.registry.url}/${ image.prefix}/${ artifactId}</repository> <tag>${ project.version}</tag> <buildArgs> <JAR_FILE>${ project.build.finalName}.jar</JAR_FILE> </buildArgs> </configuration> </plugin>插件里使用的docker.registry.url和image.prefix是我单独为Docker的镜像仓库设置的属性。
<properties><java.version>1.8</java.version> <image.prefix>kevinyan</image.prefix> <docker.registry.url></private.registry.url> </properties>这里可以随意设置成私有仓库的远程地址和镜像前缀，比如在阿里云的镜像服务上创建一个叫docker-demo的空间，上面的属性就需要这样配置：
<properties> <java.version>1.8</java.version> <image.prefix>docker-demo</image.prefix> <docker.registry.url>registry.cn-beijing.aliyuncs.com</docker.registry.url> </properties>在POM文件里配置好插件后伴随着我们打包应用执行mvc clean package操作时dockerfile-maven-plugin就会自动根据我们的配置打包好一个叫做kevinyan/hello-spring:0.0.1-SNAPSHOT的Docker镜像。
dockerfile-maven-plugin除了能帮助我们打包应用镜像外还可以让它帮助我们把镜像push到远端仓库，不过我觉得用处不大，感兴趣的同学可以去网上搜搜看这部分功能怎么配置。
Docker的多阶段构建打包镜像上面介绍了使用Maven插件帮助我们打包Java应用的镜像，其实我们还可以把mvn clean package这一步也交给Docker来完成。当然把Java应用的源码放在Docker镜像里再编译打包在发布出去肯定是有问题的，我们知道在Dockerfile里每个指令ADD、RUN这些都是在单独的层上进行，指令越多会造成镜像越大，而且包含Java项目的源码也是一种风险。
不过好在后来Docker支持了多阶段构建，允许我们在一个Dockerfile里定义多个构建阶段，先拉起一个容器完成用于的构建，比如说我们可以在这个阶段里完成JAR的打包，然后第二个阶段重新使用一个jre镜像把上阶段打包好的JAR文件拷贝到新的镜像里。
使用下面的Dockerfile可以通过多阶段构建完成Java应用的Docker镜像打包。
# Dockerfile也可以不放在项目目录下，通过 -f 指定Dockerfile的位置，比如在项目根下执行以下命令docker build -t <some tag> -f <dirPath/Dockerfile> .FROM kevinyan/aliyun-mvn:0.0.1 AS MAVEN_BUILDCOPY pom.xml /build/ COPY src /build/srcWORKDIR /build/ # mount anonymous host directory as .m2 storage for contianerVOLUME /root/.m2RUN mvn clean package -Dmaven.test.skip=true --quietFROM openjdk:8-jre COPY --from=MAVEN_BUILD /build/target/*.jar /app/application.jarENTRYPOINT ["java", "-jar", "/app/application.jar"]上面我们用的这些Dockerfile也可以不用放在项目的根目录里，现在已经支持通过 -f 指定Dockerfile的位置，比如在项目根下执行以下命令完成镜像的打包。
docker build -t kevinyan/hello-spring:0.0.1 -f <dirPath/Dockerfile> .上面第一个镜像是我自己做的，因为Maven官方的镜像的远程仓库慢的一批，只能自己包装一下走阿里云的镜像源了。试了试速度也不快，主要是随随便便一个Spring项目依赖就太多了。大家如果这块有什么加快Docker 构建速度的方法也可以留言一起讨论讨论。
不可否认用多阶段构建打出来的Go镜像基本上是M左右，但是Spring的应用随随便便就是上百兆，这个对容器的构建速度、网络传输成本是有影响的，那么Spring应用的镜像怎么瘦身呢，这个就留到以后的文章进行探讨了。
原文：/post/
