这个功能，就是两三分钟的事，马上就搞定了。
改造后的代码：
<!--轮播图 --> <div id="kinMaxShow" > <#if bannerPhotoList??&& bannerPhotoList?size gt 0 > <#list
bannerPhotoList as item> <div> <img height="350px" src="${base}/image/${item.url}" /> </div> </#list> <#else> <div> <img src="${static}/image/index/banner/4.jpg" /> </div> <div> <img src="${static}/image/index/banner/2.jpg" /> </div> <div> <img src="${static}/image/index/banner/3.jpg" /> </div> </#if> </div> 问题出现了： 自从使用了动态的图片，轮播图的图片高度没有占满“350px” 。图片的上下都有空白。非常可恶。推測： 后端代码的问题。 经过对照2种情况生成的HTML，全然一样，除了图片地址不一样。不知道。经过了多久的Chrome查看元素。突然意识到是不是图片有问题了。去查看图片，发现高度仅仅有250。
尼玛，真把老子当250了。坑爹货啊。因此，事实证明，图片上传后，经过了压缩，高度变成了250了。
期间。我也debug SpringMVC图片上传的代码。进入到后台的时候。图片已经变小了。因此。图片变小是WebUploader图片上传组件干的好事。
网上搜索WebUploader的资料，“WebUploader图片压缩” ，零散地找到了一些资料。
WebUploader的官网打开非常慢，通过百度快照，看了 WebUploader API文档。 有这么一点内容： compress {Object} [可选] 配置压缩的图片的选项。
假设此选项为false, 则图片在上传前不进行压缩。
默觉得： { width: 1600, height: 1600, // 图片质量。仅仅有type为`image/jpeg`的时候才有效。 quality: 90, // 是否同意放大，假设想要生成小图的时候不失真。此选项应该设置为false. allowMagnify: false, // 是否同意裁剪。 crop: false, // 是否保留头部meta信息。 preserveHeaders: true, // 假设发现压缩后文件大小比原来还大，则使用原来图片 // 此属性可能会影响图片自己主动纠正功能 noCompressIfLarger: false, // 单位字节，假设图片大小小于此值。不会採用压缩。 compressSize: 0 } 能够清楚地知道，这个组件有压缩功能，在满足一定的条件下会压缩。为了方便，直接在upload.js中添加“ compress:false, ” 不压缩，这个时候。上传图片就是“原样”了。至于 上面配置的“width:1600px”，我推測是图片的宽度和高度达到一定条件就压缩。
总结：
kinMaxShow轮播组件没有问题，WebUploader看到图片太大非常不爽，就启用了压缩。解决这个问题的思路：发现了问题，分析问题的类型，推測。验证。网上搜资料，找准关键词。本次搜索关键词“WebUploader 压缩” 。射线-的正式启动2创业旅程2015年3月18日 23时间湖北-武汉-循礼门
转载于:https://www.cnblogs.com/bhlsheji/p/5041392.html
