【重点】 1.页面跳转问题 header(脚本);//实现立即跳转 header功能：发送响应信息【告知浏览器重新定位到指定的脚本】要求响应头信息要先于响应主体【这也就是为什么header前不能输出的原因（因为输出在header前，相当于响应主体先于响应头（header））】 header的功能就是在脚本中实现脚本中直接发送给浏览器指定的响应信息【要求浏览器重新发送请求。就算前面有输出，也不能显示（包括语法错误的问题）】
已经解决header的问题 【在框架中使用header，需要注意header出现的时机】 php有一个输出缓存的机制，会将输出的结果全部缓存起来【也能回避header的语法报错机制（需要进行配置）】 【header的应用场景：不需要提示信息，直接进行跳转的情景。针对重定向的问题，对自己脚本的请求的处理】 【与location.href等js的跳转方式进行区别】 【另外meta标签 Refresh进行重新刷新的设置URL进行页面的刷新】
输出：echo之类的输出，php标记之外的内容相当于HTML代码也是输出
【项目中的跳转实现】 将跳转的方法写在公共基类里【控制器基类中，实现跳转的基本方法，并且传入想跳转到的页面】 【公司项目是使用display_javascript方法进行统一管理】【也可以考虑使用meta标签进行跳转控制】
【另外：跳转代码执行之后，脚本中剩余的代码并不会停止执行（这一点要牢记，如果header之后使用exit）】 【以上就是跳转的问题】
2.项目的公共类 framework文件夹中使用公共类【实现共享的效果】
考虑到共有的东西【那些公共的方法和配置（配置上实现是静态成员）】
【公司框架中使用的公共类文件（inc.php）中实现了配置和自定义自动加载的函数（自定义函数内使用include函数，并且通过注册函数实现注册【注册函数和方法进行区别】），以及分发的机制】 【自定义的autoload函数通过spl_autoload_register函数来实现注册为自动加载函数，将该加载的方法进入SPL__autoload函数栈中】 【自定义的自动加载函数能够使得我们的自动加载机制更加灵活，在框架中对自动加载机制进行重写】 【http://www.jb51.net/article/29624.htm】
3.对系统进行配置管理 设置一个配置文件系统【进行所有配置信息的初始化】 【在系统中添加一个配置文件，将该文件载入其中】 【配置信息的单独修改配置即可】
在配置文件中，将整个数组return，即可在包含之后，对配置文件中数据的读取 【return也不是一定需要的，但是为了语法上规范】 【使用return之后，可以在包含文件的语句直接进行赋值处理（将赋值之后的变量设为global变量）】 <?php return $config_array = array();//这里实现配置即可 ?>
4.流程【对一个框架下的访问流程有一个深刻认识】 【从入口开始的每一步的动作进行流程的控制】【这里新加了跳转实现和公共类以及配置文件的数据加载实现】
5.实现框架之后，在针对的控制器内添加方法便能实现我们需要的业务逻辑【这就是日常做的工作】
6.实现会话机制
判断用户的登录状态的标示【回话和cookie】
这样的验证判断的好处就在于回避了用户的重复登录。【方便但是不安全，所以系统的安全性需要对登录状态标示进行加强（防止xss）】
【对登录凭证的判断要优先，然后根据情形来进行设置凭证：和服务器缓存一个道理（优先使用和判断创建）】
由于需要跨脚本的变量的判断创建，所以session和cookie都是跨脚本的（而且保存方式也是全局的）【但是不跨域】
这就是根据我们对登录标示的需要而使用的标示符的跨脚本和保存设置的用途【因为我们需要多个脚本进行判断登录】
php的变量都是脚本级别的，所以在脚本停止之后，会销毁该变量【即使是global这样的变量，在脚本执行结束之后，对该变量的操作，也会全部失效】
【php本身不存在持久的数据，变量都是暂时存在和变更，如果不存入文本或者数据库（数据持久化），那么在脚本中对该变量的所有改变，都会由于脚本结束而失效】
【现在关于php的疑问消除了大半，就算同一个用户调用几个脚本，脚本间创建的对象也是会销毁。单例其实还是针对一个系统中太过复杂，由于代码全部在入口中执行，一个脚本中可能会出现多次对数据库的连接初始化，单例解决的就是这个问题】
【结合http本身是无状态的，就算是同一个ip发来的不同请求，并不会被认为有状态保留，现在完全解决】
【http无状态和php脚本级别的变量，使得我们同一个用户的不同请求也是不同请求，并没有关联】
【重点：解决了单例带来的疑问，但是还是注意所谓的对象池的概念】
所以解决这个问题，只能是在浏览器加标识码外加服务器进行验证该标识码【这也就是所谓的登录状态标示】【在http请求时进行这些标识码的发送和接受判断，实现对用户状态的判断】
注意：
（1）.cookie数据只能是字符串数据【数据传输过程中本身就只能是字符串型】
（2）.setcookie函数能够实现增，删，改，查只能使用$_COOKIE进行读取
（3）.cookie的失效【通过设置时进行规定时限。默认是临时cookie，保存到浏览器关闭】
【setcookie函数本身的作用就是服务器要求浏览器对cookie进行设置的指令，通过http】
（4）.cookie有效路径：只在当前目录以及后代目录内有效【不能回溯到之前路径】
（5）.子域名【cookie严格区分域名，但是子域名之间可以进行共享。也就是跨域问题，但是如果想要实现全站支持（也就是说子域名支持的话，需要通过参数设置）】
（6）.根据cookie设置的机制就可以知道，在脚本中进行设置cookie的命令，在当前脚本是不可用的【不可用或者是上一次设置后的cookie】【这一点毫无疑问】
【session】
为了提高服务器对用户访问的控制
【在cookie中加用户识别的表示码，使用session来保存用户操作的相关数据】
session的价值就是保存这些数据实现将来的数据价值【大数据的数据源】
【由于session需要服务器开启写文件的权限，所以session需要特殊进行session_start()。实现session开启操作】
【会话的机制】
通过cookie和session的结合实现会话
首先浏览器通过cookie中保存的标示，发送请求到服务器。
服务器首先执行脚本中的session_start()方法来实现session机制的启用。
然后使用session值进行session判断，并且保存脚本中实现保存的机制。
操作session的命令在当前的脚本中也是不能直接进行读取的【和cookie其效果一样，session的写入是脚本执行结束后才会写入session文件中】
【session中进行数据的序列化然后保存数据，session在脚本运行中，将session内的变量都保存在$_SESSION变量中，在脚本结束时，变量$_SESSION会消失，但是在消失前进行写入session文件】【这就是session最基础的内容】
【session运行的脚本和服务器上的文件交互的次数在脚本开始运行和脚本运行结束之后只交互两次】
【session_start()开始读操作】
【脚本结束之后开始写操作】
【在脚本运行中对session变量的操作只是单纯php的变量的操作】
【注意session_start()前不能输出，就是因为http请求头和主体的问题，因为session_start()是对服务器进行配置。因为session变量是针对服务器而言的，所以不能使用输出】
【对header和session两种情况前不使用输出的原因的解释】