一个理性者思考的是什么该做，什么不该做，什么时候做，应该怎么做，都会有一个相对精确的答案，而一个感性者，多数时候都将取决于当前的心前，如果好那么就做，如果再好点，那么就多做一点，做的更好一点，如果不好那就算了，甚至什么也不做。正因为如此，一个单纯的理性者，往往缺乏变化，总是那副死板的模样，而感性者也太多变化，以至于自己都高不清楚自己。试想，如果可以将二者进行适当的结合，理性中稍带感性，一成不变的生活中不经意间的一次小小改变，也许就是极大的惊喜。

风险越大，潜在的收益也就越大，但仅仅在风险是可控的前提下才成立。当风险可控时，这不是冒险，是在赌博。那么什么的风险才是可控的呢？首先的分析潜在的风险可能在何处、何地、何时发生，这样的分析必须建立在一定的数据基础上，而单纯的考经验进行分析往往是极度不准确的。拿软件工程来说，项目初期对项目可能的开发成本、周期进行评估，即便是有类似项目的开发经验，但是由于软件的特殊性，所以即便如此所做出的评估也不不够准确，更多的也就依赖于项目管理人员的经验了。然而无论怎么进行评估，都存在一个极大的风险，该风险来自于用户，完全可以认为用户也不知道他想要的是什么，所以需求变更是在正常不过的事了，无论软件的架构如何好，但是要知道软件的架构都是建立在需求的基础上的，所以当需求发生变更后，修改是在所难免的，而对于某些变更甚至可能导致整个软件需要重新架构。

其次是来自开发团队的人员风险，首先并不是人员越多就越好，人员越多也就意味着需要更多的沟通成本，很有可能这种沟通成本会高于多人合作所带来的好处，所以项目管理者必须决定合适的人数。另外由于人员的水平差异，和流动的的不确定性，所以还的选择合适的人选，前者比较好控制，然而后者相对来说就比较难了，一旦项目进行到一定的阶段，突然发生人员流失，这时要么选择新人的加入，或者在项目组中找其他人进行顶替，无论何种情况，都需要后人在短时间内熟悉前人的任务以及他的遗留物，这必然对整个项目的进度或多或少的造成延迟。

有这么一台计算机，F和M进程可以共同创建一个C进程，同时会把其拥有的资源复制给C，但在一般情况下并不会终结C进程，即使F和M自然终结。F和M所赋予C的资源中，自然不乏各种变量，但是C却没有完全操控这些变量的权限，其只有简单的使用全，也许你会误认为这是全局变量，其实不然，这些只不过是固化到硬件的变量而已，虽然C没有权限清理这些变量，但是当一定周期后，这些变量会主动出栈。

C在运行期间自然会创建各种各样的线程，并负责调度这些线程，为了保证这些线程能够正常运行，自然需要栈和各种变量的支持，不断有变量的进进出出，对于C来说，这些变量有些是主动的，当然也有些是被动的。同时有极少一部分变量会长期存在与栈中，直到C进程的运行空间发生转移，或者发生不可预见的异常，然后进行一次大规模的清栈，也就不得不消息了。。。

也许有一天你会发现C进程的栈中多了一个特殊变量，其生命周期甚至并不因为C进程运行空间的改变而发生变化，但是其仍然只是一个变量，只不过是C专属私有变量而已，只是C对其有更高的权限，甚至在C的运行空间发生改变时主动或者影响其地址空间的改变而已。当一个不可避免的事件触发后，自然这个变量这就该出栈了。

1. 定义一个iframe标签，并设置为hidden

<iframe id="hiddenFrame" style="visibility: hidden"></iframe>

2. 定义一个form,action属性设置为相应的文件下载链接,同样设置为hidden,并将target属性设置为上一步定义的iframe的id

<form id="hiddenForm" action="export.action" method="post"
    target="hiddenFrame" style="visibility: hidden;">
</form>

3. 当需要下载文件时，通过js将上一步定义的form提交，当然如果需要传递参数，通过js将相应的参数加入form中即可

var form = document.getElementById('hiddenForm');
var input = document.createElement("input");
input.setAttribute('name', 'option');
input.setAttribute('value', '123');
form.appendChild(input);
if (options) {
    for(var op in options){
        input = document.createElement("input");
        input.setAttribute('name', op);
        input.setAttribute('value', options[op]);
        form.appendChild(input);
    }
}
form.submit();
form.innerHTML = '';

最近做的一个项目中用到了Spring AOP,在做单元测试时都没发现有任何异样，但是当运行在服务器上后，突然有一次查看日志时发现所有的AOP方法重复执行了4次，简单的找了一下原因，没找到。由于AOP方法只是做参数校验和简单的权限控制，所以在开发期间，重复执行是可以接受的，所以就没管了，直到今天第二次认真的来解决这个问题。之前也在网上查了不少资料，但是都没有发现有这样的问题，难道这不应该是个问题。。。没办法，只好自己慢慢排查了，断点跟踪发现，Spirng加载进去的AOP方法确实是重复了4次，突然想到aop:config配置所在的文件在另外3个文件中进行了import引用，这样算下来刚好是4，如果推测不错的话，那么就是由于import导致aop:config重复加载导致的这个原因，果断把aop:config放到不被引用的文件中，再次运行，发现问题解决了。。。

下午查了一下Spring的官方文档，发现并没有说名import究竟如何工作，只是简单的说明这样可以各逻辑层的bean配置在不同的文件中，方便管理，倒是说了可以有多个aop:config，那么这么看来import会导致同一个aop:config被当做不容的aop:config进行加载，自然也就存在重复了，所以以后在项目中为了避免在不知情的情况下引用其他存在aop:config的配置文件，尽量的aop:config单独配置比较好。