之前处理过类似问题，如果容器宽度可以确定，那么一行能容纳多少字就可以确定。文字长度/每行字数=行数，分页就自己发挥吧

echart有api，后台只要喂数据即可，难点在于数据库设计要符合分析，就要涉及到数据仓库，数据模型，前端模型配合后台数据模型，才是完整的解决方案

img作为内容和文字放一起，设置浮动，文字会自动围绕图片，然后具体调样式，记住，inline/inline-block的dom都会和所在行文字对齐的特点。

思路没有错，我只能说面试的人很好像。做产品什么都需要自己开发么，在非核心功能组件上，采用插件不了避免。再说js插件本来就是前端一个特点。

$(".content p").click(function(){ $(".box").append($(this));})

一个循环就出来了，符合条件+1，算好后除以数据的length，就可以了。要做通用的写成function。munberpy可能这样的统计函数，但是为了这个小功能，引入专业的数据统计库没有必要。

bootstrap grid col，最好严格按照这种结构，不然后期你会悲剧的

javascript 的this主要是看如何调用这个函数，而不是这个函数所在的作用域。obj.fn() fn中的 this 就是 obj。 fn() this是undifine, 而在js进入函数之前，会有 if(!this) { this = window} 这样的操作。因此，后面那个this是window。

javascript 的this主要是看如何调用这个函数，而不是这个函数所在的作用域。obj.fn() fn中的 this 就是 obj。 fn() this是undifine, 而在js进入函数之前，会有 if(!this) { this = window} 这样的操作。因此，后面那个this是window。

javascript 的this主要是看如何调用这个函数，而不是这个函数所在的作用域。obj.fn() fn中的 this 就是 obj。 fn() this是undifine, 而在js进入函数之前，会有 if(!this) { this = window} 这样的操作。因此，后面那个this是window。

javascript 的this主要是看如何调用这个函数，而不是这个函数所在的作用域。obj.fn() fn中的 this 就是 obj。 fn() this是undifine, 而在js进入函数之前，会有 if(!this) { this = window} 这样的操作。因此，后面那个this是window。

create view，视图除了不能增删改，当做普通表一样处理就可以了。视图灵活在于，视图本身就是通过sql获得结果，如果你去看执行计划可以发展其实就是一段sql查询，物理视图除外。

响应式布局就是为了这样的应用而生，为什么不用呢，难道你要每种主流的设备做不同的页面，然后通过判断设备类型来重定向到不同页面吗？

无解，不同浏览器，渲染还不同，还是做个假的替换吧。

屏幕下滑是scroll事件，在scroll事件中，掩藏浮动bar弹出的menu

单独页面相对特殊，一般公共样式，配合本页的样式。功能组件样式分离开，一个功能块一个，多个功能组件样式也可以组合放一起，需要配合js使用的功能样式，最好独立出来，否则后期很乱

卡死现象一般是你改了py文件导致的，我感觉是个bug，有时候改了能立马生效，有时候就会出现卡死现象，这种时候，通常我就直接ctrol +c，重开。

column 类型不一样吧，mysql应该会有强制转换，用int处理下再join试试

jbox插件，看看适不适合你，不用什么东西都自己写。

百分比应该是根据父元素决定，至少在日常布局可以这样运用。楼上说的margin会被推上父元素的现象，是margin collapse，中文不打好翻译，可以设置父元素的padding属性防止